软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：
分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：
细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c语言中的封装原则以及设计模式中的Facade(外观)模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don&39;tcallus,we&39;llcallyou。
以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们就来看一下当前流行的技术，以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架构谈起：
因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。cmp和entitybean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。推荐作为持久层的首选
在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中sessionbean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。
在用户结构层,虽然servlet/jsp/jstl/javaBean能够实现MVC架构，但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。
随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档 *** 作工具(DOM,Digester,SAX等)的使用愈发重要，而随着xmlschema的javabinding工具(jaxb,xmlbean等)工具的成熟，采用xmlschema来设计xml文档格式，然后采用javabinding来生成javabean会成为主要编程模式,而这又进一步使数据中心向xml转移，使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。现还有一个趋势，microsoft,ibm等纷纷大量开发中间软件如(microsoftoffice之infopath)，可以直接从xmlschema生成录入页面等非常实用的功能。还有webservice的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现还很难定论。
aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。也许作为一个很好的思想，它将在webservice里大展身手。
rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。
随着信息系统规模不断扩大、复杂程度日益提高，体系结构模式对信息系统性能的影响越来越大不同功能的信息系统对体系结构模式有不同的要求，各种体系结构模式的信息系统在开发和应用过程中也有很大的区别。选择和设计合理的体系结构模式甚至比算法设计和数据结构设计更重要。 单用户体系结构
单用户信息系统是早期最简单的信息系统，整个信息系统运行在一台计算机上，由一个用户占用全部资源，不同用户之间不共享和交换数据。
C/S体系结构
C/S（Client/Server）结构，即客户机和服务器结构。这种体系结构模式是以数据库服务器为中心、以客户机为网络基础、在信息系统软件支持下的两层结构模型。这种体系结构中，用户 *** 作模块布置在客户机上，数据存储在服务器上的数据库中。客户机依靠服务器获得所需要的网络资源，而服务器为客户机提供网络必须的资源。目前大多数信息系统是采用Client/Server结构。
B/S体系结构
B/S（Browser/Server）结构，即浏览器服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面通过浏览器来实现，极少部分事务逻辑在前端（Browser）实现，主要事务逻辑在服务器端（Server）实现，形成所谓三层结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本。
P2P体系结构
P2P（P to P）体系结构，即对等网络结构。P2P体系结构取消了服务器的中心地位，各个系统内计算机可以通过交换直接共享计算机资源和服务。在这种体系结构中，计算机可对其他计算机的要求进行响应，请求响应范围和方式都根据具体应用程序不同而有不同的选择。目前对等网络模式有纯P2P模式、集中模式及混合模式，是迅速发展的一种新型网络结构模式。 单用户体系结构因为功能简单和不支持网络功能，虽然对软硬件的要求都很少，只可用于开发不需要网络的单机小规模信息系统。本节主要分析和比较C/S体系结构、B/S体系结构和P2P体系结构。
软硬件要求
C/S体系结构根据系统规模需要相应的硬件配置，一般建立在小范围网络环境上，局域网之间再通过专门服务器提供连接和数据交换服务。C/S程序可以更加注重流程，可以对权限多层次校验，对系统运行速度可以较少考虑。
B/S体系结构由于用户界面主要事务逻辑完全在服务器端通过浏览器实现，客户端一般的硬件配置均能满足要求，网络也不必是专门的网络硬件环境，但应用服务器运行数据负荷较重，需要更加优化的系统结构和相应硬件配置。
P2P体系结构要求用户使用专门的客户端软件，不同的信息系统和客户端软件对硬件配置的要求有很大的区别。
系统开发的投入
P2P体系结构不需要建立成本高昂的服务器平台，特别是立足现有网络建立起的P2P体系结构信息系统几乎没有成本。
B/S体系结构系统开发的投入与用户的多少无关，部署代价比较小，尤其适合开发客户较多，使用频繁的信息系统。
C/S体系结构系统部署代价与信息点的多少成正比，可用于开发小型信息系统。
维护与功能扩展
B/S体系结构只需维护服务器，所有的客户端只是浏览器，不需要任何维护和管理，而且只需将服务器连接专网，即可实现远程维护、升级和共享。
C/S体系结构维护复杂，处理出现的问题以及系统升级困难，系统扩展性不好。
P2P体系结构系统内计算机配置和使用各不相同，维护和扩展工作较为复杂。
安全与稳定
C/S一般面向相对固定的用户群，对信息安全的控制能力很强，一般高度机密的信息系统采用C/S结构适宜。
B/S建立在广域网之上，面向不可知的用户群，对安全的控制能力相对弱一点。
P2P体系结构网络内大多数计算机由不同用户控制，网络相对混乱，系统整体效果存在问题不可预见，系统安全与稳定方面存在很大的风险，但由于信息分布在不同的计算机上，不会因为一台计算机的故障导致整个系统的瘫痪。 概况
许多单位和管理机构通过ERP 来管理企业或机构的整体业务流程，整合企业资源，提高生产效率，考核人员工作效率．Unitsoft EBS系统立足于此类企业，将管理工作中综合信息因素纳入管理系统，实行宏观、统一、适时的管理，提高工作效率，降低企业成本，有效整合企业资源。
系统功能需求分析
作为单位和管理机构的管理系统，具有一定复杂性，经过分析，Unitsoft EBS系统主要应满足下列要求：
1 实现对分布于全球各地的分支机构进行集中控管。
2 不同公司采用虚拟集团模式进行一体化 *** 作，财务上实现独立核算。
3 业务员业绩考核系统，实现计划目标，达成业绩，回款状况，费用综合考核，科学计算奖金的激励方案。
4 通过客户关系管理使销售过程可视化，提高销售机会转化率
注重过程管理才能使结果可控，客户关系系统按照客户定位，发现，联系，拜访，建立关系，确定机会，持续跟进，签单，后续服务的过程，与客户维持良好的关系，把客户一步一步往前推进，提高销售机会转化率，从而提高最终接单率。
5 敏捷的售前分析，快速订单响应，控制接单风险
通过订单综合评估，快速响应客户订货要求并赢得订单；通过订单全程跟踪了解订单执行情况，以便给客户做出恰当、明确的承诺；
通过订单综合评估（客户等级、信用、价格、付款条件、订单交期），快速响应客户订货要求并赢得订单；
对于订单的变更，以MRP为纽带实现销售、采购、委外、生产的快速联动，通过对销售、采购、委外、生产的变更管理，快速响应客户；
通过订单全程跟踪了解订单执行情况，以便给客户做出恰当、明确的承诺。
6 完备的供应商和客户管理
通过完备的供应商和客户档案管理，集中统一管理供应商和客户，及时进行供应商资格认定与信用评估，从而降低经营风险。
7 灵活规范的价格体系，满足不同客户的需要
严格按照既定价格政策报价，如全部产品执行统一价格，不同级别客户执行不同价格，个别客户特价等，避免销售人员随意报价。系统能够追踪价格历史版本，使得出现问题有据可查。
8 严格的信用管理，控制赊销与应收风险
通过信用管理，确定控制信用的对象（客户、业务员、部门）和信用控制的方式（信用额度和信用期限），并可以设置控制的单据、触发信用控制的时点、超信用的处理方式及对应的额度的审核，保证用户能真正控制住信用额度、信用期限。
9 严密的采购价格控制，降低采购成本
通过采购询价比价，请购与采购订单三个环节，实时控制采购最高进价，如高于最高进价，系统予以提示，并自动进入审批流程，报请采购主管审批后才可通过，从而帮助供应主管规范采购业务，降低采购成本。
10 以MRP为核心,协调销售，生产，仓库，采购等部门，确保及时交货
通过配置BOM快速按客户需求完成产品配置；
系统快速准确下达生产和采购计划，使得计划合理可行，生产周期缩短；
通过信息关联进行生产任务全程跟踪，发现问题及时处理，保证按期交货。
11 实时业务追踪
帮助企业实时的了解客户订单在库存、供应环节的详细进度，能够实时监控订单的满足情况和可能发生的例外。
12 多层次的库存控制，防止库存积压和短缺
以MRP为核心准确计算生产物料需求，合理制定采购策略，与库存策略保障供需平衡；
通过实时控制可用量，保证库存的连续性，库存展望等多角度的分析帮助库管加强可预见性，合理保证库存，优化资金占用。
13 多种预警设置，及时提醒决策
通过灵巧的工作流机制，自动推进业务流程，及时提醒，提高工作效率。
14 持续优化成本, 提高成本核算的精准度和及时性
存货自动核算机制，准确掌握原材料消耗的成本；
全面收集生产人工，设备，能耗，管理费用等，并科学的分摊到每个订单，每种产品，体现真实的成本。
15 业务财务同步管理
通过业务财务同步管理，规范了企业的销售、生产、采购、库存管理，并可依据凭证追溯到每一项业务，达到真正的业务监控，也可控制和协调企业的各种计划和预算。
体系结构模式的选择
根据系统功能需求和主要模块设计，系统用户较多，功能复杂，存储信息量大，需要专业技术人员维护和管理系统。在体系结构模式选择过程中，尽量立足于现有网络，在满足安全与稳定要求的同时，使管理维护 *** 作简单，减少开发投入。
单用户体系结构不能满足本系统网络要求；C/S体系结构过于庞大，管理维护复杂；P2P体系结构虽然功能强大，但是本系统并不需要即时通讯和不间断的数据更新。为使用户能够在简单、易用、单一、统一的可视化界面下，轻松、方便地访问到各种类型的数据，Unitsoft EBS系统采用B/S体系结构。
系统主要模块设计 模块 1．客户管理 2．市场开发管 理 3报价管理 4．销售机会管理 5．销售合同管理 功
能
简
介 ·客户信息
·联系人管理
·客户分类与状态
·信用管理
·联系历史
·客户分配
·客户权限控制 ·日程管理
·任务管理
·销售活动管理
·客户拜访与报告
·销售日周月报
·历史信息查询
·事件提醒 ·价格管理
·报价助手
·报价单生成
·报价单审批 ·客户需求
·成本预算
·报价方案
·报价与跟踪
·审批控制
·备货管理 ·合同编制
·合同审批
·合同生成
·合同执行控制
·合同状态管理
·发货开单
·附件管理 模块 6．采购询价管理 7．采购合同管理 8．库存管理 9．进出口管理 10．运输管理 功
能
简
介 ·供应商资料
·供应商询价
·供应商比价
·采购价格管理 ·采购合同编制
·采购审批
·采购订单生成
·采购执行状态 ·采购入库管理
·生产入库管理
·其他入库管理
·销售出库管理
·领料出库管理
·其他出库管理
·存货盘点
·存货核算
·出入库检验
·批次管理 ·货物明细
·报关资料与单证
·结汇单证
·开票资料
·配额与许可证
·外运管理
·保险与索赔
·信用证管理
·核销与退税 ·发货运输
·采购运输
·运输费用
·运费结算 模块 11．应收款管理 12．应付款管理 13．财务系统 14生产数据管理 15物料需求管理 功
能
简
介 ·应收款录入
·预收款控制
·收款结算
·应收款查询
·应收款统计分析 ·应付款录入
·付款结算
·应付款查询
·应付款统计分析 ·基础设置
·期初设置
·凭证处理
·记帐
·银行对帐
·帐簿管理
·辅助核算
·自动转帐
·现金流量
·资产负债表
·损益表
·电子报表 ·多级BOM管理
·成本BOM
·工序工艺管理 ·物料需求
·MRP运算
·物料请购
·物料状态跟踪 模块 16生产过程管理 17．生成成本核算 18．系统平台 功
能
简
介 ·生产任务管理
·外协管理
·派工管理
·领料管理
·生产入库
·生产日报
·工序检验
·计时计件工资
·设备管理 ·材料成本归集
·成本分摊标准设置
·部门公耗费用分摊
·部门制造费用分摊
·完工与在制品成本
·单品成本
·订单成本 ·Unitware商务中间件
基础组件、业务组件、XML扩展组件
·工作流
消息的传递、流程驱动、事件提醒
·权限管理
组权限、用户权限、跨公司权限、金子塔和扁平化组织结构、互联网访问控制
·系统基础管理
包括产品与物料管理、分支机构、职员、职位、客户分类、业务类型、打印模版、文档模版、系统代码、基础资料等 模块 19．虚拟集团管理 20．费用管理 21．销售业绩核算 22条码管理 23电子商务 功
能
简
介 ·分公司间订单管理
·分公司物流管理
·多组织财务独立核算
·跨公司权限管理 ·费用报销
·费用审核
·费用支付
·费用统计 ·目标设置
·算法与参数设置
·应收款汇总
·回款
·呆账处理
·提成计算 ·产品条码
·出入库扫描
·批次自配
·包装数与数量换算 ·会员管理
·在线客服
·询价管理
·采购管理
·样品管理
·业务查询
·物流查询
·结算查询 数据库设计
Unitsfot EBS系统的后台数据库采用MS SQL Server。
Unitsoft EBS系统的实现
服务器采用Windows 2003server *** 作系统，使用MS SQL Server数据库管理系统作为数据库平台，网络协议采用标准>
你可以结合AJAX与onkey（）与setInterverl()方法实现间隔性请求，但这会给服务器造成崩溃的灾难！
正确的方法涉及到了侦听器， WebSocket ,内容过多，打字不易，还是不说了
Serverless（无服务器架构）是指服务端逻辑由开发者实现，应用运行在无状态的计算容器中，由事件触发，完全被第三方管理，其业务层面的状态则存储在数据库或其他介质中。
Serverless可以使开发者更聚焦在业务逻辑，而减少对基础设施的关注。
Serverless通常包含了两个领域 BaaS（Backend as a Service）和 FaaS（Function as a Service）
BaaS是一种广泛依赖于第三方应用和服务的无服务器计算方法。BaaS供应商可以提供加密、用户认证、云数据库的使用。这些服务可以通过调用云供应商提供的API进行访问；相比自己重新开发，这些功能可以更方便地整合到各个类型的系统中。
FaaS 是一种事件驱动的由消息触发的服务，FaaS 供应商一般会集成各种同步和异步的事件（如AWS的SNS），通过订阅这些事件，可以触发指定的函数运行，例如当前使用很广泛的 AWS 的 Lambda函数。
Serverless架构的优点
降低运营成本：
Serverless是非常简单的外包解决方案。它可以让您委托服务提供商管理服务器、数据库和应用程序甚至逻辑。由于这个服务使用者的数量会非常庞大，于是就会产生规模经济效应。在降低成本上包含了两个方面，即基础设施的成本和人员（运营/开发/维护）的成本。
降低开发成本：
Serverless作为一种云服务，使得整个应用程序组件被商品化。
扩展能力：
横向扩展是完全自动的、有d性的、且由服务提供者所管理。从基本的基础设施方面受益最大的好处是，您只需支付您所需要的计算能力。
更简单的管理：
Serverless架构明显比其他架构更简单。更少的组件，就意味着您的管理开销会更少。
有效利用计算资源：
据《福布斯》的统计，在商业和企业数据中心的典型服务器仅提供5%～15%的平均最大处理能力的输出。这无疑是一种资源的巨大浪费。Serverless让服务提供商提供我们的计算能力最大限度满足实时需求，更有效地利用计算资源。
Serverless架构的缺点
状态管理：
要想实现自由的缩放，无状态是必须的，而对于有状态的服务，使用serverless这就丧失了灵活性。
延迟：
Serverless应用程序是高度分布式、低耦合的，这就意味着延迟将始终是一个问题，单纯使用serverless的应用程序是不太现实的。
本地测试：
Serverless应用的本地测试困难是一个很棘手的问题。虽然可以在测试环境下使用各种数据库和消息队列来模拟生产环境，但是对于无服务应用的集成或者端到端测试很困难。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）