原文地址：微服务架构概述
博客地址：http://blog.720ui.com/

传统的单体架构，使用三层架构，包括视图表现层、业务逻辑层与数据访问层，其划分的目的是为了更好地规划软件系统的逻辑结构，便于开发与维护。单体架构将整个应用系统视为一个整体，部署在同一个 Web 容器。例如，一个 VR 资讯系统包含资讯模块、话题模块、日报模块、百科模块等多个模块，在单体架构中，所有的功能模块都在同一个应用系统中，并且共同使用一个数据库。

单体架构的好处在于，所有的功能模块都在同一个应用系统中，非常容易开发与测试。但是，随着系统规模的不断扩大，业务需求的不断迭代，系统功能的持续增加，传统的单体架构面对的问题也越来越多，主要体现在几个方面：

开发效率变低。所有的功能模块都在同一个应用系统中，团队成员需要共同维护同一套工程代码，势必增加了相应的沟通成本与协作成本。
维护成本增加。业务需求的不断迭代与系统功能的持续增加，使得这个应用系统变得越来越庞大，越来越复杂。一方面，开发人员在开发功能与修复缺陷的成本变高，另一方面，新加入团队的成员也需要花费巨大的精力去熟悉这个巨无霸的业务系统。
部署影响变大。系统规模的不断扩大，带来的另外一个后果就是构建时间变长。每次新功能版本发布，或修复缺陷重新部署，这个过程将导致应用系统不可用，相当于系统宕机，影响面较大。
可扩展性较差。应用系统作为一个业务强耦合的整体，无论是水平扩展还是垂直扩展，都存在扩展性问题。
技术选型成本高。单体架构技术选型相对而言比较单一，很难平滑替换新的技术。

随着敏捷开发、持续交付、虚拟化技术、DevOps 理论的实践，微服务架构应运而生，并逐渐使得应用架构朝着高可用性、可扩展性、可伸缩性发展的方向演进。ThoughtWorks 公司的首席科学家 Martin Fowler 对微服务进行了描述，他说到：“微服务是一种将单个应用划分成许多小的服务来构建软件的架构模式。每个服务运行在自己的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务和各自独立的自动化部署机制构建而来。每个服务需要极少的集中管理，因此可以使用不同的编程语言以及不同的存储技术。”。Martin Fowler 还列举了微服务的九个特征，包括通过服务实现组件化、围绕业务能力进行组织、基于产品而不是项目、智能端点与哑管道、去中心化治理、去中心化数据管理、基础设施自动化、为故障而生、演进的设计。如果对Martin Fowler 的微服务描述感兴趣，可以阅读 https://martinfowler.com/articles/microservices.html。

请读者思考，微服务的拆分粒度多小，才能算是“微”?一般情况下，拆分粒度应该保证微服务具有业务的独立性与完整性，因此微服务的拆分围绕业务模块进行拆分。那么，这里将 VR 资讯系统进行服务拆分，分为资讯系统、话题系统、日报系统、百科系统四个微服务系统，每个微服务独立使用一个数据库。

微服务带来的价值，主要体现在几个方面：

每个微服务易于开发和维护，便于沟通与协作，很适合小团队敏捷开发与持续交付。
每个微服务职责单一，高内聚、低耦合。同时，每个微服务能够独立开发、独立运行、独立部署。
每个微服务之间是独立的，如果某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响。
每个微服务可以随着系统规模的不断扩大，面对海量用户和高并发，独立做水平扩展与垂直扩展。
每个微服务可以使用不同的编程语言以及不同的存储技术，使得我们更容易尝试新的技术。此外，对单个服务进行业务重构，也不会面临很大的业务负担与技术债卷。

微服务不是银弹，它也带来了一些技术的复杂度。因此，我们需要思考与解决分布式的复杂性、事务的一致性、服务的管理与运维、服务的自动化部署等解决方案。

总结下，随着系统规模的不断扩大，业务需求的不断迭代，系统功能的持续增加，传统的单体架构面对的问题也越来越多。并且互联网产品需求变化快、用户量大，传统的单体架构显得力不从心。而随着敏捷开发、持续交付、虚拟化技术、DevOps 理论的实践，微服务架构取代了传统的单体架构，将单个应用划分成许多小的服务，服务与服务间采用基于 HTTP 协议的 RESTful API 通信。在收获微服务带来的价值的同时，需要解决微服务带来的一些技术的复杂度问题。

（完）

更多精彩文章，尽在「服务端思维」微信公众号！