软件设计：单体应用与分布式系统

　　在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。

　　单体应用

　　单体应用简单讲就是把一个系统所涉及的各个组件都打包成一个一体化结构并进行部署和运行。

　　在JavaEE领域，一体化结构很多时候体现为一个WAR包，而部署和运行的环境就是以Tomcat、weblogic为代表的各种应用服务器

　　应用服务器上同时运行面向用户的web组件、封装业务逻辑的service组件、数据访问的DAO（dataaccessobject，数据访问对象）组件。这些组件作为一个整体进行统一开发、部署、维护。

　　优点：

　　团队规模不太大时，单体应用可由一个开发团队独立维护，因为结构简单，所以团队成员能对单体应用快速学习、理解、修改。单体应用表现形式一般是一个独立的WAR包，对它进行集成、部署、实现无状态集群比较简单，通常使用负载均衡运行多个相同的实例就能实现系统的伸缩性

　　缺点：

　　当业务复杂度高时，可扩展性差：单体应用中对系统业务的任何一处进行修改，都需要重新构建这个系统并进行发布

　　代码腐化：单体应用缺乏合理的业务和技术实现边界，随着产品业务功能增多，出现缺陷时则有可能引起缺陷的原因组合就较多，这会导致分析、定位、修复缺陷的成本增高，即缺陷的平均修复时间可能较长。随着功能的增加，单体应用的代码结构也越来越复杂，在开发人员对全局功能缺乏深度理解的情况下，修复一个缺陷的同时还可能引入其他的缺陷。在自动化测试不完善的情况下，可能导致问题越修越多的情况

　　在单体应用中所有的业务和代码很大程度上无序地混合在一起，存在大量错综复杂的业务和代码结构、由于历史原因所造成的迥然不同的开发风格以及看似复杂但已经不被使用的遗留代码，使新员工了解行业背景、熟悉应用程序业务、配置本地开发环境变得困难。随着应用程序的复杂性逐渐增加以及功能越来越多，如果团队希望尝试引入新的框架和技术，或对现有技术栈进行升级，通常会面临较大的风险，即初始的技术选型严重限制了单体应用未来采用不同开发语言或框架的能力

　　分布式系统

　　分布式系统是指硬件或软件组件分布在不同的网络计算机上，彼此之间仅通过消息传递进行通信和协调的系统。

　　在设计和实现分布式系统时需要考虑：

　　网络：分布式系统的所有组件都位于网络之中，对于互联网应用而言，则位于更为复杂的互联网环境中

　　通信和协调：位于分布式系统中的各个组件只有通过约定、高效且可靠的通信机制进行相关协作才能完成某一项业务功能

　　分布式系统两种拆分思路

　　纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的应用系统。纵向拆分关注于业务，通过梳理产品线，将内聚度较高的相关业务进行剥离从而形成不同的子系统

　　横向拆分：横向拆分更多地关注于技术。横向拆分通过将可以复用的业务拆分出来，独立部署为分布式服务，调用这些分布式服务，构建复杂的新业务。横向拆分的关键在于识别可复用的业务，设计服务接口并规范服务依赖关系

　　分布式系统的挑战

　　网络传输的三态性：构建分布式系统依赖网络通信，而网络通信表现为一个复杂且不可控的过程。相比单机系统中函数式调用的失败或者成功，网络通信会出现三态性，即成功、失败、超时。由于网络原因，消息没有成功发送到接收方，而是在发送过程中发生了丢失现象；或者接收方处理后，响应给发送方的过程中发生消息丢失现象。这些问题会增加通信的代价，如何使通信的代价降到用户可以忍耐的层次是分布式系统设计的首要目标

　　异构性：分布式系统由于基于不同的网络、不同的操作系统、不同的软件实现技术体系，必须要考虑一种通用的服务集成和交互方式来屏蔽异构系统之间的差异。异构系统之间的不同处理方式会对系统设计和开发带来难度和挑战

　　负载均衡：由于分布式系统是多机协同工作的系统，为了提高系统的整体效率和吞吐量，必须考虑最大程度发挥每个节点的作用。负载均衡是保证系统运行效率的关键技术

　　数据一致性：在分布式系统中，数据被分散或复制到不同的机器上，如何保证各台主机之间的数据一致性将成为一个难点。因为网络的异常会导致分布式系统中只有部分节点能够正常通信，从而形成了网络分区(NetworkPartition，可理解为脑裂)

　　系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件(middleware)负责实现这个模型。一个著名的分布式系统的例子是万维网(WorldWideWeb)，在万维网中，所有的一切看起来就好像是一个文档(Web页面)一样。