微服务架构（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