微服务架构（MSA）

什么是微服务架构

从业界的讨论来看，微服务本身并没有一个严格的定义。不过，ThoughtWorks的首席科学家（Martin Flowler）的描述更加通俗易懂：

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

原文如下：

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

– James Lewis and Martin Fowler

微服务架构的特征

微服务的本质特征通常包括如下几个部分：

• 服务作为组件（Componentization via Services）
• 围绕业务组织团队（Organized around Business Capabilities）
• 产品不是项目（Products not Projects）
• 强化终端及弱化通道（Smart endpoints and dumb pipes）
• 分散治理（Decentralized Governance）
• 分散数据管理（Decentralized Data Management）
• 基础设施自动化（Infrastructure Automation）
• 容错性设计（Design for failure）
• 演进式架构（Evolutionary Design）

微服务是一种全新的互联网架构，它的基本理念是将一个肥大的系统拆分成若干小的服务组件，组件之间的通讯采用轻量的协议完成，譬如REST API。微服务本质上是SOA (Serviceoriented Architecture) 的扩展延伸。相对来说，微服务的可操作性更强，可以逐步安排合理资源，对一个大的系统进行分解，或是至少停止让它继续臃肿下去。

微服务具有如下优点：

• 按照业务功能的独立垂直开发，易于开发、理解和维护；
• 支持异构开发语言，不会受限于任何技术栈；
• 部署周期短，自动化部署（Docker / Kubernetes）；
• 局部修改很容易部署，有利于持续集成和持续交付；
• 故障隔离，一个服务出现问题不会影响整个应用；

单体应用 vs 微服务应用

通俗地讲，“单体应用（monolith application）”就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、WAR、EAR或其它归档格式。单体应用有如下优点：

• 适合小团队创业初期进行快速开发；
• 易于测试：因为没有额外的依赖，每项测试都可以在部署完成后立刻开始；
• 部署简单：只需将单个归档文件复制到Tomcat webapps目录下；
• 不存在分布式事务问题；

但是，不管如何模块化，单体应用最终都会因为团队壮大、接入应用越来越多等出现问题。主要体现在如下方面:

• 不够灵活：对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率；
• 妨碍持续交付：单体应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付。
• 受技术栈限制：对于这类应用，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言
• 某个服务出现OOM后对整体应用产生影响；

参考资料

1.Microservices by Martin Fowler
2.Microservices Resource Guide
3.Microservices: Decomposing Applications for Deployability and Scalability