之所以想讲这个微服务架构，是因为自己在工作的经历过程中有遇到过一个使用了6年的庞大系统，最后被重构成微服务架构的经历。

如果你有幸去面试一些互联网公司，或许你会遇到面试官问你微服务架构的知识。如果你不知道什么是微服务架构，和为什么需要它，那么这篇很适合小白的你，读一读。

01 没有微服务架构前

当时负责维护的是一个比较大的平台网站，最初这个平台选择的技术栈是yaf框架+mysql+前端。当时搭建开发的这个平台并没有前后端分离的思想。所以使用的是MVC的那一套，后端前端都写在一起。

业务在不多的情况下，使用MVC并没有什么大问题，核心的压力都是在后端需要对接前端功能。随着这个系统的功能不断完善和业务拓展，这个系统的代码变得不断庞大。而原本的单平台内又诞生出了ERP系统，PC端和移动端。全部的代码都集成在了这一个yaf框架内。整个网站平台的全部源码都在这一份源码里了。

看似这个平台只要把不同的后台模块分布在不同的服务器上访问，共同调用一个核心的数据库可以运行就万事大吉了。

但是由于这个代码的平台从最初的搭建到后面的不断子系统开发，由于技术团队人员轮换，这份源码经手的开发人员换了一批又一批。不同的技术leader要求的规范也变得不一样，要求的编码规范也不一致。由于前端的源码也是在这个框架内。对于后端开发人员编写的前端对接功能上，可能并没有前端开发人员那么规范。整份代码变得冗肿，代码不够规范，开发人员开发效率低下，在它的基础上扩展业务和功能已经变得麻烦。而网站的性能瓶颈也开始遇到问题，这时就想到要对这整个系统进行重构，对不同的模块进行拆分。

但是需要注意的是，并不是把系统架构切换到微服务架构就一切顺利没有弊端。每一种架构有优点也有缺点，当把服务拆分成微服务架构后，由于模块变多，对于开发、运维、测试来说涉及的工作量都增加了。

02 什么是微服务架构？

微服务大师 Martin Fowler 是这样定义微服务架构的。他认为微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用 HTTP 资源 API 这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。

我们把他的话单独拆开来一句一句理解：

1、微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统的。

原本开发一个系统是针对应用系统来开发，现在是把一个应用系统拆分成多个小型服务来开发。

2、每个小型服务都运行在自己的进程中，并经常采用 HTTP 资源 API 这样轻量的机制来相互通信

拆分后的小型服务独立运行，拥有自己的进程，进程间互不影响。如果两个服务需要通讯，则可以使用定义的通讯（一般使用HTTP）方式通讯。

3、服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署

将原来的系统针对业务进行构建时，需要针对原本的业务功能进行模块化重构成小型服务。然后部署这些小型服务时，就需要采用全自动的部署机制，不能使用旧的方式部署。（可能不同服务可能放在不同服务器上，所以运维的管理工作相对会增加）

4、微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术

微服务的开发技术上，同一个架构中不限制你使用的语言并存在一个系统中，对于选择的数据库也不约束。

5、对这些微服务我们仅做最低限度的集中管理

微服务使用的是自上而下的模块各自独立，看似分散的结构，但是还是需要对这些微服务做好集中管理。

所谓微服务架构，就是将应用拆分为一套小且互相关联的服务。一个微服务一般完成某个特定的功能，比如订单管理、客户管理等。每个微服务都是一个微型应用，有着自己六边形架构，包括商业逻辑和各种接口。有的微服务通过暴露 API 被别的微服务或者应用客户端所用；有的微服务则通过网页 UI 实现。在运行时，每个实例通常是一个云虚拟机或者 Docker 容器。Chris Richardson 补充了微服务的运行环境，可以是云虚拟机，也可以是 Docker 容器。随着 Docker 技术的进步，微服务才真正的走向各个领域，被广泛应用起来。

03 微服务架构的特点

我们知道了什么是微服务后，那么我们看看它有什么特点。也正是因为它的特点才会被我们pick。

1、特性一：“组件化”与“多服务”

通过分解巨大单体应用为多个微服务的方法，解决了单体系统复杂性的问题。从而实现组件化和多服务。

2、特性二：围绕“业务功能”组织团队

当在寻求将一个大型应用系统分解成几部分时，公司管理层往往会聚焦在技术层面上，这就意味着要组建用户界面团队、服务器端团队和数据库团队。

每个微服务都可以有专门开发团队来开发，开发人员可以自由选择开发技术，只需要按照开发标准，提供统一的 API 服务。

3、特性三：“去中心化”的治理技术

每个微服务允许使用不同的技术来开发， 且数据可以不再单独的保存在一个数据库中，允许多种数据库技术。

4、高内聚低耦合的设计

组成各个应用的微服务，都要尽可能地实现“高内聚和低耦合”的目标，每个微服务都拥有自己的领域边界和完整的业务逻辑。

5、容错设计和弹性设计

当服务发生故障时，能够快速地试错，能够快速地检测出故障，而且能够在一定的情况下自动恢复。

6、“基础设施”自动化

基础设施例如服务器、数据库、中间件等能够弹性且自动化分配资源，微服务迭代构建要能够满足自动化的提交版本、自动化代码检查、自动化测试、自动化部署以及监控等。

正是因为微服务架构拥有这些特点才慢慢的被越来越多的互联网公司所选择。

但是这也并不是一本万利的好事，我们也来看看微服务架构所带来的缺点。

04 它的缺点

前面说到微服务也有一些坑，那么都有什么坑呢？我们把所涉及到的开发人员都放到一起说一说。

• 设计人员：单体架构一般是三层设计，微服务架构其实也不例外，只是在这三层的基础上要更细化，要梳理出微服务的边界，并非微服务颗粒度划分越细越好，这个度要按照业务领域来设计，要更清晰地设计出每个 API 输入好输出参数，要考虑高可用、高性能和可扩展性等，还要考虑其他中间件的应用，由此由此会带来许多固有的复杂性。
• 开发人员：微服务架构提高了开发的技术门槛。如果采用了微服务架构，那么几乎不可避免地会遇到分布式事务的一致性问题，这是微服务架构的经典问题，业界也有很多种解决办法，但是也并不是万能的。开发人员必须写代码来处理消息传递中的延迟、丢失或者不可用等问题，并做好补偿措施。如果还采用了数据库的分库分表，那么你还会遇到跨库查询的难题。
• 测试人员：微服务架构增加了测试复杂度。对于单体架构 ，测试它的 API 是很容易的事情，但是对于微服务，测试人员要明确知道它的关联服务，清楚地知道服务的消费者和提供者，以及它们的环境配置部署节点等。此外还要清楚中间件逻辑，例如反向代理、负载均衡算法、缓存策略等。
• 运维人员：微服务架构增加了运维部署的复杂度。对于单体架构，直接将部署包发布到服务器上即可，但是对于微服务，需要部署到不同的服务器上，同时要注意服务之间的调用的先后顺序以及启动顺序。还要直观地看到服务调用链，服务器访问关系，应用系统接口调用关系等，这时候你必须有一套完善且强大的监控体系，才能运维好采用微服务架构的分布式系统，否则一旦出现系统级的故障，单体架构你还可以通过简单快速的重启解决，而面对调用链路复杂，服务器庞大的分布式系统，你根本就无从下手。

所以在选择微服务架构时，也要看好利弊综合考虑再选择该架构。当然这也是架构师们所要考虑的事情了。但是如果你能够站在架构师的角度去思考问题，你会在思考中不断地进步。