看到最近“微服务架构”这个概念这么火，作为一个积极上进的程序猿，成小胖忍不住想要学习学习。而架构师老王（不是隔壁老王）最近刚好在做公司基础服务的微服务化研究和落地，对此深有研究。

于是成小胖马上屁颠屁颠的跑过去向老王请教：“王哥，我看微服务架构这么火，我也想学，您给我讲讲啥是微服务架构呗？”

老王笑了笑说：“要想知道什么是微服务架构，你得先知道什么系统架构设计。”

成小胖的理想是成为一名架构师，平时积累了不少知识，因此对“系统架构设计”这个概念还是很熟悉的，因此他马上就给出了答案^【1】：

系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定的价值的方式。

老王满意的点点头，继续问：“你看最近我在做微服务的研究和落地，你知道为什么要做这个事情吗？”

“因为目前的三层架构存在很多弊端，不满足业务发展的需求了呗。”

“对的，我看你对公司目前的架构也非常熟悉了，你来仔细说说现在的三层架构吧。”

于是成小胖拿了一张A4纸，图文并茂地给老王讲了他对三层架构的理解：

三层架构是指在业务和技术的发展过程中，系统中不同职责的部分被定义在不同的层次，每一层负责的功能更加具体化。三层架构通常包括表示层、业务逻辑层和数据访问层，层与层之间互相连接、互相协作，构成一个整体，并且层的内部可以被替换成其他可以工作的部分，但对整体的影响不大。

以 Web 应用程序为例，早期是将所有的表示逻辑、业务逻辑和数据访问逻辑放在一起，这就是一层架构。

后来随着 java、.NET 等高级语言的发展，提供了越来越方便的数据访问机制，如 java 的 JDBC 和 .NET 的 ADO.NET。这时数据访问部分被分离开来，形成了二层架构。

再后来，随着面向对象设计、企业架构模式等理念的不断发展，表示逻辑和业务逻辑也被分离开来，形成了现在的三层架构。

三层架构的具体内容如下：

• 表示层： 用户使用应用程序时，看到的、听见的、输入的或者交互的部分。
• 业务逻辑层： 根据用户输入的信息，进行逻辑计算或者业务处理的部分。
• 数据访问层： 关注有效地操作原始数据的部分，如将数据存储到存储介质（如数据库、文件系统）及从存储介质中读取数据等。

老王对这个解释非常满意，作了进一步的补充：“你看虽然现在程序被分成了三层，但只是逻辑上的分层，并不是物理上的分层。也就是说，对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。而这，就是所谓的单块架构。”

成小胖挠了挠头：“原来单块架构是这个意思啊~~”

“嗯。根据你的实际工作经验，你再总结下单块架构的优缺点吧。”

平时勤于总结的成小胖很快便列出了单块架构的优缺点：

 优点：

• 易于开发： 开发方式简单，IDE 支持好，方便运行和调试。
• 易于测试： 所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。
• 易于部署： 只需要将打好的一个软件包发布到服务器即可。
• 易于水平伸缩： 只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序（当然也需要采取分发策略保证请求能有效地分发到新节点）。

缺点：

• 维护成本大： 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
• 持续交付周期长： 构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。
• 新人培养周期长： 新成员了解背景、熟悉业务和配置环境的时间越来越长。
• 技术选型成本高： 单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
• 可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。

老王拍了拍成小胖的肩膀，眼睛眯成了一条缝：“小伙子总结的很不错！既然你已经对目前的单块架构的优缺点有了很好的理解，那现在咱们就可以开始来学习微服务架构了。”

老王先从网上搜索“微服务架构”关键字，出来这么一段话：

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

成小胖看完了这段话，说：“看着有点晕，云里雾里的感觉……”

老王嘿嘿一笑：“莫慌，现在就给你详细讲讲微服务架构的特性。” 

1. 单一职责

微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。

2. 轻量级通信

服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。

对于轻量级通信的格式而言，我们熟悉的 XML 和 JSON，它们是语言无关、平台无关的；对于通信的协议而言，通常基于 HTTP，能让服务间的通信变得标准化、无状态化。目前大家熟悉的 REST（Representational State Transfer）是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。

3. 独立性

每个服务在应用交付过程中，独立地开发、测试和部署。

在单块架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。

在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。

4. 进程隔离

单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。

有时候我们会将重复的代码抽取出来封装成组件，在单块架构中，组件通常的形态叫做共享库（如 jar 包或者 DLL），但是当程序运行时，所有组件最终也会被加载到同一进程中运行。

在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。

理论上所有服务可以部署在同一个服务器节点，但是并不推荐这么做，因为微服务架构的主旨就是高度自治和高度隔离。

“王哥你真厉害，您这么一说我的思维清晰了很多！”成小胖激动的几乎要叫起来。

“我之前了解过 SOA，好像跟微服务架构的思想很像啊，您能帮我区分一下吗？”成小胖追问到。

老王嘿嘿一笑，拿起