干货：软件架构详解

什么是架构

计算机科学和程序设计的飞速发展，使得软件设计应用到从航空航天到平常生活的方方面面。单我的开发一段小程序的作法早就过期，大范围协做的工程化时代随即到来。

随着大范围协做的效率问题和软件复杂度的爆炸式增加，管理和技术方面的各类不肯定性也爆发性增长，致使软件开发的质量没法获得有效保证，周期和成本没法获得有效控制。

人们一直在寻求找到这些问题的解决办法。然而 Fred Brooks 在 1975 年出版的软件工程圣经《人月神话》中说，没有（能解决全部问题的）银弹（There is no silver bullet）。

自此，人们发展了项目研发过程管理来控制管理活动的不肯定性，同时也发展了软件架构设计方法来控制技术方面的不肯定性。

进而在实践中不断的总结和改进，用于有效指导和最大程度的保障软件开发的质量、周期和成本。

架构的定义

架构（Architecture）一词源于建筑领域，其自己就是建筑的意思，也是体系结构的意思。维基百科英文版里对 Architecture 的解释是：规划、设计和建造建筑物的过程及产物。

鉴于软件工程与建筑工程同样是一项系统的工程性工做，引入到计算机领域后，软件架构就成为了描述软件规划设计技术的专有名词。

特别地，软件架构师一词在英文里，和建筑师也是同一个词（Architect）。

维基百科里对软件架构的定义：

软件架构是有关软件总体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操做、逻辑和流程。软件架构是一个系统的草图。

软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的链接则明确和相对细致地描述组件之间的通信。

在实现阶段，这些抽象组件被细化为实际的组件，好比具体某个类或者对象。在面向对象领域中，组件之间的链接一般用接口来实现。

比较公认的软件架构定义是在 2000 年的 ANSI/IEEE 1471 标准中定义的：

1. 架构过程：在系统整个生命周期中构思、定义、表达、记录、交流，验证合适实现，维护和改进架构的过程，也就是设计过程。

2. 架构：一个系统体如今其环境中的元素、关系的基本概念或属性，以及其设计和进化原则。

3. 架构描述：表达一个架构的工做产出物（一般指的是各类架构图和设计文档）。

4. 架构视图：经过系统的某些关注点的视角，表达一个系统的工做产出物（例如部署视图、开发视图等）。

5. 系统：包含了一个或多个进程、硬件、软件、工具与能够知足需求的人的集合。

6. 环境：决定了开发、操做、策略和其余影响系统的设置和条件。

在 UML 中，架构则被认为是系统的组织结构和相关行为。架构可被分解为经过接口互联部分的关系，以及相互做用。

经过接口相互做用的部分包括类、组件和子系统。这样就能够经过 UML 的各类架构图来描述这些对象和关系，从而表达清楚一个系统的架构。

总结

软件架构是一个用于指导系统实现的草图，这个草图越详细对于系统实现的指导意义越重大，贯穿于软件的整个生命周期。

在建筑领域，大楼还没有建造前，就已经存在于建筑师的脑海里；一样地，系统开始编写第一行代码以前，就已经存在于软件架构师的内心。

几个相关概念

模式（Pattern）

UML 中给出的解释更通俗易懂：模式是对于广泛问题的广泛解决方案。

咱们能够把一类问题的共性抽象出来，这样就能够用一样的处理办法去解决这些问题，从而造成模式，因此模式是一些经验的总结。

类库（Library）

类库是一组可复用的功能或工具的集合，应用系统经过调用它们从而达到复用功能的目的。

例如，Windows 应用开发里的各类静态或动态连接库 DLL 文件，Java 开发中项目里依赖的或者 Maven 中央库里的各类 jar 包，都是 Library，好比 Apache Commons IO、HttpClient，Log4j 等。

框架（Framework）

框架是基于一组类库或工具，在特定领域里根据必定的规则组合成的、开放性的应用骨架。

好比 SSM/SSH 框架，更大范围来讲 Dotnet Framework、JDK 都算是一种框架。

关于框架与架构的关系，Vasyl Boroviak 曾在 Stack Overflow 网站上经过两张图作了形象的对比，以下所示。

• 框架：

• 架构：

模块（Module）

模块是业务或系统的安装特定维度的一种切分，同时也能够看作是各类功能按照某种分类聚合的一种形式。

例如咱们的一个电商系统，能够从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块、售后模块等。

另外一方面，咱们也能够说用户模块聚合了用户注册、用户验证等业务功能。

组件（Component）

组件是一组能够复用的业务功能的集合，包含一些对象及其行为。

组件能够直接被用作业务系统的组成部分，粒度通常小于模块，也是一种功能的聚合形式。好比日志组件、权限组件等。

服务（Service）

服务是一组对外提供业务处理能力的功能，服务须要使用明确的接口方式（好比 WebService 或 Rest 等）。

服务描述里应该包括约束和策略（好比参数、返回值，使用什么通信协议和数据格式等）。

平台（Platform）

平台通常来讲，是一个领域或方向上的生态系统，是不少解决方案的集大成者，提供了不少的服务、接口、规范、标准、功能、工具等。

例如 J2EE 平台，包含了企业级应用开发里的各类基于 Java 语言和 JVM 虚拟机运行时的技术能力。

知乎社区编程领域优秀问题回答者 ze ran 说：

库是工具箱。

框架是一套通用的解决方案。

架构是高度抽象的需求，是系统中的不变量。

平台是全部可能作的事的集合。

从软件的生命周期看架构设计

设计期

在设计期，软件做为一个成品还不存在，因此咱们能够称之为概念形态。

此时架构师、产品经理或需求分析师等人员利用本身的经验能力，对系统的业务需求进行分析、拆解、抽象，造成业务文档和技术文档，以及技术验证代码等。

这个阶段，架构设计工做是重中之重，其中包括：

• 系统分拆：如何把系统拆解为不一样的子系统、模块、业务单元；

• 技术选型：使用什么样的基础技术框架或脚手架；

• 技术验证：肯定核心技术难点如何解决，检验可否知足指望指标；

• 接口规范：系统的内部不一样部分以何种形式肯定接口契约和数据通讯；

• 集成方式：系统与外部其余业务系统如何进行集成；

• 技术规范：如何规范开发、测试、部署和运维的技术标准性；

• 部署方案：系统如何进行物理部署，须要多少机器、什么配置，对网络有什么要求；

• 运维方案：系统如何进行技术性运维，如何平常监控、预警报警；

• ……

这个阶段总结一下就是：业务为要，架构先行（包括业务架构和技术架构）。

实现期

这个阶段主要是编码与测试，准备部署上线，是软件从代码到最终的生产系统的过程，咱们能够称之为代码形态。此阶段须要考虑的技术类工做包括：

• 确保各项技术规范和技术指标的执行落地，保障高质量的代码；

• 指导研发人员和解决各种技术问题，提高研发团队效率；

• 制定测试的技术性方案和基准，自动化、性能、安全等；

• 配合准备部署环境，运维实施方案落地等。

运行期

这个阶段系统上线、验收经过，已经初步稳定，而后进入维护阶段，成为了设计期架构设计草图的一个可用实例，咱们能够称之为实例形态。此时须要考虑：

• 发布上线相关基础性工做，包括是否使用持续集成（CI)、自动化发布等技术；

• 运维基础性工做，自动化运维，监控等相关技术。

架构的形式与特色

设计文档和代码

咱们通常说的架构既包括架构的设计过程，也包括设计的产出物，通常能够包括各种设计文档、设计图，也能够包括一些技术验证代码、Demo 或者其余相关程序。

文档的目的在于准确记录咱们的思惟产物，在软件还没有实现时，做为指导蓝图，尽可能精确的描述清楚软件。

在软件的实现过程当中，可能随时随着咱们的深刻研究，根据具体状况对文档作出局部的一些调整和修改。

文档做为结项或交接的一部分，也是整个软件项目的产出物的一部分，成为公司 IT 资产的有机组成部分。

架构服务于业务

正如 19 世纪的伟大建筑师路易斯•沙利文（Louis Sullivan）倡导的建筑设计著名格言：“功能决定形式（Form follows function）”。

软件架构首先是要服务于业务功能的。

架构影响研发团队的组织形式

业务拆分的方法和技术框架的选择必然会影响到研发团队的组织形式。

业务拆分的越细致，越有利于咱们更好的对项目的各项指标量化计算，更精确的估计工时和成本，从而指导咱们每一个小组应该分配多少资源，使用什么样的协同和任务确认形式。

而且随着项目的推动，计划与实际状况之间的匹配程度也随时能够进一步精确调整，进而影响到咱们应该对每一块任务的投入资源进行动态调整。

架构存在于每个系统

每个已经实现并运行的系统，都是特定架构设计的载体。

有些系统对应的架构，有详细的设计文档来描述；有些系统的设计文档，残缺不全，甚至还由于在系统的发展变化的同时，文档没有更新，致使设计文档与实际系统不符。

有些系统干脆就没有设计文档。

可是这些系统，都是基于必定的架构来建立的。

每种架构都有特定的架构风格

每种架构方式，每一个具体系统内所体现的架构设计，都是能够被工程师们理解，进而提炼出来一些架构思想和设计原则，这些思想和原则就是这种架构方式的风格。

依据这些风格，咱们能够将各类架构方式，进行分门别类，从而进一步讨论每种架构风格的特色。

架构须要不断的发展演进

随着计算机软硬件的不断发展，软件架构思想也在不断的发展变化。

另外一方面，软件为其提供业务处理和服务能力的每一个具体行业领域也在不断发展变化，业务处理流程、参与角色、业务形式不断的推陈出新。

这就要求咱们在系统架构设计时，保持终身学习的精神，持续吸取新思想新知识，保持贴近一线业务群体，随时因地制宜，调整架构设计，采起最适合当下场景的解决方案。

架构的目标与方法

明确软件系统架构的一些通用目标，可使咱们更明确如何考虑架构的方向；而了解架构的方法和方法论，则让咱们能够知道从哪些角度能够比较全面的描述清楚一个系统的架构设计。

可控性与拆分

对于复杂问题的简化处理，一个简单办法就是分而治之。

按必定的粒度把目标问题进行分解，能够很是有效的提高目标的可控性，使得目标变得更加能够量化、进而优化。

系统按照合适的粒度拆分红不一样模块的过程，咱们通常称为模块化。模块化也是软件工程化的基础。

在这个基础上才可以实现分工合做。

复用性与抽象

复用性一直是软件设计领域的一个很重要的指标。

复用的一个关键是咱们对于现有具体问题的抽象，找到各类不一样问题中存在的不变性，进而做为一种通用结构来统一处理。

拆成是把总体变成不少局部，再对局部分开对待和研究其性质。

反过来，咱们按照高内聚的指导思想把一些紧密联系的功能聚合后，打包成一个能够总体复用的部分，这就是组件，这个过程就是组件化。

经过组件化，咱们能够获得抽象再组合出来不少业务组件。这样，在更大粒度上实现了功能的复用。

非功能性需求九维目标

（1）高性能

系统必须知足预期的性能目标，在并发用户数（Concurrent Users）、并发事务数（Transactions per Second，TPS）、吞吐量（Throughout）等指标方面达到预估值，支撑使用人群的正常使用操做。

（2）可靠性

业务系统直接影响到用户的经营和管理，所以必须是可靠的。

（3） 稳定性

软件系统必须是可以在用户的使用周期内长期稳定运行的。这要求系统具备必定的容错能力。

（4）可用性

可用性是指系统在指定时间内的提供服务能力的几率值。咱们通常采起集群、分布式等手段提高系统的可用性。

高可用性是目前系统架构设计方面的一个热点。

（5）安全性

用户的业务数据是具备很是高的商业价值，若是被泄露或篡改将会带来重大损失。

安全性是软件系统的一个重要的指标，也是架构设计的一个重要目标。

（6）灵活性

软件系统应该具有知足不一样特色的用户群和目标市场的能力，更灵活。

（7）易用性

软件系统必须拥有较好的用户体验，便于用户使用。

（8）可扩展性

业务和技术都在不断的发展变化，软件系统须要随时根据变化扩展改造的能力。

（9）可维护性

软件系统的维护包括修复现有的错误，以及将新的需求和改进添加到已有系统。

所以一个易于维护的系统对于用户提出的问题或改进，能够及时的实现高效的反馈和响应支持，同时有效下降维护成本。

基于这些目标，常常有人说：“架构是系统非功能性需求的解决办法的集合”。

架构的不一样风格

典型的企业级应用系统或者互联网应用系统通常都是经过 Web 提供一组业务服务能力。

这类系统包括提供给用户操做的、运行于浏览器中、具备 UI 的业务逻辑展现和输入部分，运行于服务器端、用后端编程语言构建的业务逻辑处理部分，以及用于存储业务数据的关系数据库或其余类型的存储软件。

根据软件系统在运行期的表现风格和部署结构，咱们能够粗略地将其划分为两大类。

（1）整个系统的全部功能单元，总体部署到同一个进程（全部代码能够打包成 1 个或多个文件），咱们能够称之为 “单体架构”（Monolithic Architecture）；

（2）整个系统的功能单元分散到不一样的进程，而后由多个进程共同提供不一样的业务能力，咱们称之为 “分布式架构”（Distributed Architecture）。

再结合软件系统在整个生命周期的特色，咱们能够进一步区分不一样的架构风格。

对于单体架构，咱们根据设计期和开发实现期的不一样模式和划分结构，能够分为：

• 简单单体模式：代码层面没有拆分，全部的业务逻辑都在一个项目（Project）里打包成一个二进制的编译后文件，经过这个文件进行部署，并提供业务能力；

• MVC 模式：系统内每一个模块的功能组件按照不一样的职责划分为模型（Model）、视图（View）、控制器（Controller）等角色，并以此来组织研发实现工做；

• 先后端分离模式：将先后端代码耦合的设计改成前端逻辑和后端逻辑独立编写实现的处理模式；

• 组件模式：系统的每个模块拆分为一个子项目（SubProject），每一个模块独立编译打包成一个组件，而后全部须要的组件一块儿再部署到同一个容器里；

• 类库模式：A 系统须要复用 B 系统的某些功能，这时能够直接把 B 系统的某些组件做为依赖库，打包到 A 系统来使用。

对于分布式架构，咱们根据设计期的架构思想和运行期的不一样结构，能够分为：

• 面向服务架构（Service Oriented Architecture）：以业务服务的角度和服务总线的方式（通常是 WebService 与 ESB）考虑系统架构和企业 IT 治理；

• 分布式服务架构（Distributed Service Architecture）：基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理；

• 微服务架构（MicroServices Architecture）：微服务架构能够看作是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务（因此叫微服务）和一组设计准则来考虑大规模的复杂系统架构设计。

也有人把如上的各个架构风格总结为四个大的架构发展阶段：

（1）单体架构阶段

（2）垂直架构阶段

（3）SOA 架构阶段

（4）微服务架构阶段

这种分类跟前述的方式并无多大区别。咱们接下来详细介绍其中的一些重要架构风格。

单体架构：简单单体模式

简单单体模式是最简单的架构风格，全部的代码全都在一个项目中。这样研发团队的任何一我的均可以随时修改任意的一段代码，或者增长一些新的代码。

开发人员也能够只在本身的电脑上就能够随时开发、调试、测试整个系统的功能。

也不须要额外的一些依赖条件和准备步骤，咱们就能够直接编译打包整个系统代码，建立一个能够发布的二进制版本。

这种方式对于一个新团队的创立初期，须要迅速开始从 0 到 1，抓住时机实现产品最短期推向市场，能够省去各类额外的设计，直接上手干活，争取了时间，于是是很是有意义的。

可是这种方式对于一个系统的长期稳定发展确实有不少坏处的。

首先，简单单体模式的系统存在代码严重耦合的问题。全部的代码都在一块儿，就算是按照 package 来切分了不一样的模块，各不一样模块的代码仍是能够直接相互引用。

这就致使了系统内的对象间依赖关系混乱，修改一处代码，可能会影响一大片的功能没法正常使用。

第二，简单单体模式的系统变动对部署影响大，而且这个问题是全部的单体架构系统都存在的问题。

系统做为一个单体部署，每次发布的部署单元就是一个新版本的整个系统，系统内的任何业务逻辑调整都会致使整个系统的从新打包，部署、停机、再重启，进而致使了系统的停机发布时间较长。

每次发布上线都是生产系统的重大变动，这种部署模式大大提高了系统风险，下降了系统的可用性。

第三，简单单体模式的系统影响开发效率。

若是一个使用 Java 的简单单体项目代码超过 100 万行，那么在一台笔记本电脑上修改了代码后执行自动编译，可能须要等待十分钟以上，而且内存可能不够编译过程使用，这是很是难以忍受的。

第四，简单单体模式打包后的部署结构可能过于庞大，致使业务系统启动很慢，进而也会影响系统的可用性。

这一条也是全部单体架构的系统都有的问题。

第五，扩展性受限，也是全部单体架构的一个问题。

若是任何一个业务存在性能问题，那么都须要考虑多部署几个完整的实例的集群，或者再加上负载均衡设备，才能保证整个系统的性能能够支撑用户的使用。

因此，简单单体模式比较适用于规模较小的系统，特别是须要快速推出原型实现，以质量换速度的场景。

单体架构：MVC 模式

MVC 也是一个很是常见的 3 层（3-Tier）结构架构模式，它把每一个模块划分为模型层（Model Layer）、视图层（View Layer）、控制器层（Controller Layer）等部分。

• 模型层：表明业务数据实体部分；

• 视图层：表明前端的展现部分；

• 控制器层：表明请求分发，处理调度部分。

更通常地，咱们能够添加数据操做层（Data Access Layer）等，造成一个 N 层（N-Tier）结构模型。

整个系统由多个模块组成，每一个模块又由这种不一样的部分组成。这样一来，咱们就把整个系统拆解成了不少粒度较小的零件。这种方式之因此流行开来，主要是由于：

• 简单，直观，能够很是有效的上手，做为 Web 系统设计的通常方法，这一点是 MVC 模式被普及的基础条件；

• 通过上面过程的横割竖切，咱们已经把系统拆解为一个个的小单元，很是有利于分配开发工做，投入大量的工程师进行大规模的工程化开发，这一点很是重要，在软件行业高速发展的今天，适合工程化的方式才是最具备生产力的办法；

• 不一样的模块和分层结构，自己就能够做为一个开发层面的子项目拆分结构，这样咱们就能够把系统拆分红多个不一样的子项目；

• 基于 MVC 模式，又陆续发展了 ORM 等简化数据操做层的技术与框架，以及相应的代码生成工具等，极大的提供了软件开发效率。

固然，MVC 模式也存在定义不够明确，对于简单的业务场景拆解过细致使复杂度增长等问题，须要在实践中不断摸索和总结应用经验。

基于单体架构下的 MVC 模式依然解决不了单体架构自己存在的问题，特别是对于可用性和扩展性的影响。

单体架构：先后端分离模式

传统的 Web 系统都是 BS 结构的。

通常的 JSP 或页面标签 Tag 技术、后端 FreeMaker 或 Velocity 等模板技术致使 HTML/CSS/JavaScript 等前端技术与后端的处理逻辑和数据耦合到一块儿，这种方式明显不符合现代工程化的专业领域细分原则。

特别是随着富网络应用程序（Rich Internet Application，RIA）概念的兴起，Ajax 和 JQuery 框架，前端 UI 组件技术的大行其道，程序员们在浏览器端写了不少逻辑处理和界面处理的 JavaScript 代码。

后来愈来愈多的业务逻辑须要在浏览器端实现，前端技术逐渐发展到了一个百花齐放的阶段，特别是近年来基于 NodeJS 前端技术栈的成功应用，最终使前端技术成为了一个与后端技术领域并驾齐驱的领域。

其实早在 2006 年，ExtJS 做为当时的前端解决方案集大成者，已经实现了前端代码逻辑和界面所有都由 JavaScript 完成，后端只提供基于 URL 的 JSON 数据接口。

这样 Web 系统就由原来的 BS 系统，变成了提供 UI 和交互的前端 B 系统，提供数据接口的后端 S 系统，从而达到了先后端分离的目标。

自从，愈来愈多的系统采用先后端分离的模式，而且进一步影响了研发团队的组成：前端团队负责前端系统开发，后端团队负责后端系统开发，两个团队一块儿制定先后端系统的数据接口。

只要数据接口保持稳定不变，那么先后端系统能够各自独立发展和维护。这一条准则不只仅是单体架构独有的，全部的 Web 系统均可以按照这种方式进行设计。

先后端分离模式一直影响到如今的系统架构方法，成为了当下的一种最佳实践。目前最主流的三种前端开发框架（React、AngularJS、Vue），都遵循着这种设计理念。

分布式架构：面向服务架构（SOA）

• 服务与 SOA

面向服务架构（SOA）是一种建设企业 IT 生态系统的架构指导思想。SOA 的关注点是服务。服务最基本的业务功能单元，由平台中立性的接口契约来定义。

经过将业务系统服务化，能够将不一样模块解耦，各类异构系统间能够轻松实现服务调用、消息交换和资源共享。

（1）从宏观的视角来看，不一样于以往的孤立业务系统，SOA 强调整个企业 IT 生态环境是一个大的总体。整个 IT 生态中的全部业务服务构成了企业的核心 IT 资源。

各系统的业务拆解为不一样粒度和层次的模块和服务，服务能够组装到更大的粒度，不一样来源的服务能够编排到同一个处理流程，实现很是复杂的集成场景和更加丰富的业务功能。

（2）从研发的视角来看，系统的复用能够从之前代码级的粒度，扩展到业务服务的粒度；可以快速应对业务需求和集成需求的变动。

（3）从管理的角度来看，SOA 从更高的层次对整个企业 IT 生态进行统一的设计与管理，对消息处理与服务调用进行监控，优化资源配置，下降系统复杂度和综合成本，为业务流程梳理和优化提供技术支撑。

• SOA 落地方式

SOA 的落地方式与水平，跟企业 IT 特色、服务能力和发展阶段直接相关。目前常见的落地方式主要有分布式服务化和集中式管理两种。

（1）分布式服务化

互联网类型的企业，业务与技术发展快，数据基数与增量都大，并发访问量高，系统间依赖关系复杂、调用频繁，分布式服务化与服务治理迫在眉睫。

经过统一的服务化技术手段，进一步实现服务的注册与寻址、服务调用关系查找、服务调用与消息处理监控、服务质量与服务降级等等。

现有的一些分布式服务化技术有 Dubbo（基于 Java）、Finagle（基于 Scala）和 ICE（跨平台）等。

（2）集中式管理

传统企业的 IT 内部遗留系统包袱较重，资源整合很大一部分是须要打通新旧技术体系的任督二脉，因此更偏重于以 ESB 做为基础支撑技术。

以整合集成为核心，将各个新旧系统的业务能力逐渐的在 ESB 容器上聚合和集成起来。

比较流行的商业 ESB 有 IBM 的 WMB 和 Oracle 的 OSB，开源 ESB 有 Mule、ServiceMix/WSO2 ESB、JBoss ESB 和 OpenESB。

一方面，集中式管理的 SOA，其优点在于管理和集成企业内部各处散落的业务服务能力，同时一个明显的不足在于其中心化的架构方法，并不能解决各个系统本身内部的问题。

另外一方面，随着自动化测试技术、轻量级容器技术等相关技术的发展，分布式服务技术愈来愈像微服务架构方向发展。

分布式架构：微服务架构（MSA）

James Lewis 和 Martin Fowler 给微服务架构的定义以下：

微服务架构风格，以实现一组微服务的方式来开发一个独立的应用系统的方法。其中每一个小微服务都运行在本身的进程中，通常采用 HTTP 资源 API 这样轻量的机制相互通讯。

这些微服务围绕业务功能进行构建，经过全自动化的部署方式来进行独立部署。这些微服务可使用不一样的语言来编写，也可使用不一样的数据存储技术，而且基于最低限度的集中管理。

同时 Martin Fowler 总结有以下 9 个特性：

• 组件以服务的形式提供

• 围绕业务功能进行组织

• 产品而不是项目

• 强化终端与弱化管道

• “去中心化” 地治理技术署

• “去中心化” 地管理数据

• “基础设施” 自动化

• “容错” 设计

• “演进式” 设计

微服务架构能够看做是一种 SOA 的发展实现，其将 SOA 中本来可能聚合在同一个系统内的多个服务组件拆分到各自独立的系统进程。

微服务架构的优点在于：

• 更加完全的组件化，系统内部各个组件之间解耦的比较干脆，单个系统的规模小不少；

• 能够组建每一个服务独立的维护团队，利于各自团队独立的开发和维护；

• 每一个微服务独立部署，只要服务间的接口稳定，各系统能够相互之间互不干扰的独立发展；

• 微服务架构使得每一个服务自己能够独立的扩展，性能出现瓶颈，优化或增长这个服务的配置便可。

微服务架构的劣势也很明显，拆分的过细则要求自动化测试能力必须跟得上。一个全流程的测试跨 8~10 个系统是全部测试人员的恶魔。

问题的排查，数据的一致性保障，系统的监控等等，都会由于拆分的太细，复杂度大幅度增长。

若是代码或设计上有一个修改涉及到多个不一样的微服务，那么在团队之间协调配合成本也会增长。对旧系统的微服务架构和组件化改造也是一个比较大的问题。

在组件化上所作的任何工做的成功度，取决于软件与组件的匹配程度。

可是合理的组件边界应该如何肯定，这是很是困难的，演进式的处理方式是咱们以为比较合理和靠谱的。

所以，Martin Fowler 也建议，不要一上来就以微服务架构做为系统设计的起点。相反地，要用一个单块系统做为起点，并保持其模块化。

当这个单块系统出现了问题后，再将其分解为微服务。

推荐一个交流学习群：650385180里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多：