架构设计思维

1

应用架构的演变

大家认真想一下，架构为什么进行演化呢？这些年，微服务非常火，那你有没想过微服务的动机是什么？其实，最重要的动机就是业务变化太快了。特别是移动互联网出现以后，各种各样的业务：共享单车、支付宝、微信支付等等，业务经历着飞速的变革与创新，所以就要求底层的应用技术能够支撑得上业务的快速变化。那我们看一下应用架构的变迁，其实也是从另一个角度来印证上面说的“快”。

1-1

单体架构

Web应用程序发展的早期，在开发服务端企业应用时，应用需要支持各种不同类型的客户端，比如桌面浏览器、移动浏览器以及原生移动应用。应用还需要向第三方提供可访问的API，并通过Web Service或者消息代理与其它应用实现集成。大部分web工程是将所有的功能模块(service side)打包到一起并放在一个web容器中运行，很多企业的Java应用程序打包为war包。应用通过执行业务逻辑、访问数据库、与其它系统交换信息、并返回一条HTML/JSON/XML响应，来处理请求（HTTP请求与消息）。

应用采用多层架构或者六角架构，主要由以下几类不同组件构成：

• 展现组件——负责处理HTTP请求并响应HTML或者JSON/XML（对于web Services APIs）
• 业务逻辑——应用的业务逻辑
• 数据库访问逻辑——用于访问数据库的数据访问对象

不同逻辑组件分别响应应用中的不同功能模块。

单体架构的缺点

1. 单体应用巨大的代码库可能会让人望而生畏，特别是对那些团队新成员来说。应用难以被理解和进行修改，进而导致开发速度减慢。由于没有清晰的模块边界，模块化会逐渐消失。另外，由于难以正确把握代码变化，导致代码质量逐步下滑，陷入恶性循环。
2. 过载的IDE——代码库越大，IDE速度越慢，开发者的生产效率越低。
3. 过载的Web容器——应用越大，Web容器启动时间越长。容器启动耗费时间，极大影响到开发者的生产效率。对部署工作也有负面影响。
4. 持续部署困难——巨大的单体应用本身就是频繁部署的一大障碍。为了更新一个组件，你必须重新部署整个应用。这会中断那些可能与更改无关的后台任务（例如Java应用中的Quartz任务），同时可能引发问题。另外，未被更新的组件有可能无法正常启动。重新部署会增加风险，进而阻碍频繁更新。因为用户界面开发者经常需要进行快速迭代与频繁重新部署，所以这对用户界面开发者而言更加是个难题。
5. 应用扩展困难——单体架构只能进行一维伸缩。一方面，它可以通过运行多个应用副本来增加业务容量，实现扩展。一些云服务甚至可以根据负载量动态调整实例数量。但在另一方面，数据量增大会使得该架构无法伸缩。每个应用实例需要访问所有数据，导致缓存低效，加大内存占用和I/O流量。另外，不同的应用组件有不同的资源需求——有的是CPU密集型的，另外一些是内存密集型的。单体架构无法单独伸缩每个组件。
6. 难于进行规模化开发——单体应用是规模化开发的障碍。应用一旦达到特定规模，需要将现有组织拆分成多个团队，每个团队负责不同的功能模块。举例来说，我们可能需要设立UI团队、会计团队、库存团队等等。单体应用的问题在于它使团队无法独立展开工作。团队需要在工作进度和重新部署上进行协调。对于各团队而言，这使得变更和更新产品变得异常困难。

1-2

SOA架构

SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。

SOA架构的缺点

1. 可靠性（Reliability）：SOA还没有完全为事务的最高可靠性——不可否认性（nonrepudiation）、消息一定会被传送且仅传送一次（once-and-only-once delivery）以及事务撤回（rollback）——做好准备，不过等标准和实施技术成熟到可以满足这一需求的程度并不遥远。
2. 安全性（Security）：在过去，访问控制只需要登录和验证；而在SOA环境中，由于一个应用软件的组件很容易去与属于不同域的其他组件进行对话，所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。
3. 编排 （Orchestration&#x