微服务一词越来越火爆，不谈微服务仿佛就 out 了。那么什么是微服务？微服务架构与传统的 SOA 架构有什么区别？何时应该采用微服务架构？如何构建微服务？
一、什么是 MSA？
微服务架构（MicroServices Architecture， MSA）的出现并非偶然，而是与这个时代的软件技术发展有着紧密的联系。比如，
- 将业务功能服务化，是 SOA 的延续；
- RESTful 等架构的兴起，让我们可以考虑更多轻量化的通信机制；
- 领域驱动设计指导我们如何分析并模型化复杂的业务；
- 敏捷方法论帮助我们拥抱变化，快速反馈；
- 持续集成和持续交付（CI/CD）促使我们构建更快、更可靠、更频繁的软件部署和交付能力；
- 虚拟化和容器技术的发展，使我们简化了部署环境的创建、安装；
- DevOps 文化的流行以及全栈自治团队的出现，使得小团队更加全功能化。
微服务架构的定义：简言之，微服务架构风格就像是把小的服务开发成单一应用的形式，运行在其自己的进程中，并采用轻量级的机制进行通信（一般是 HTTP 资源 API）。这些服务都是围绕业务能力构建的，通过全自动部署工具来实现独立部署。这些服务可以使用不同的编程语言和不同的数据存储技术，并保持最小化集中管理。——James Lewis 和 Martin Fowler。
MSA 特征
- 组件以服务形式提供——正如其名，微服务也是面向服务的。
- 围绕业务功能进行组织——微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务，是针对业务领域有着完整实现的软件，它包含接口、持久存储以及对应的交互。
- 产品不是项目——微服务要求开发团队对软件产品的整个生命周期负责。
- 强化终端及弱化通道——微服务的应用致力于松耦合和高内聚，它们更喜欢简单的 REST 风格，而不是复杂的协议。或者采用轻量级消息总线来发布消息。
- 分散治理——微服务把整体式框架中的组件拆分成不同的服务。
- 分散数据管理——微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。
- 基础设施自动化——微服务更加依赖于基础设施自动化。
- 容错性设计——微服务应为每个应用的服务及数据中心提供日常的故障检测和恢复。
- 改进设计——微服务所提供的服务应该能够替换或者报废。
二、MSA 与 SOA
通常传统的 SOA 意味着大而全的单体架构的解决方案。这让设计、开发、测试、发布都增加了难度，其中任何细小的代码变更，都将导致整个系统需要重新测试、部署。而微服务架构恰恰把所有服务都打散，设置合理的颗粒度，各个服务间保持低耦合，每个服务都在其完整的生命周期中存活，将互相之间的影响降到最低。
SOA 需要对整个系统进行规范，而 MSA 的每个服务都可以有自己的开发语言、开发方式、灵活性大大提高。
1. SOA 架构的优点和缺点
优点：
- 1.易于开发——当前开发工具和 IDE 的目标就是支持这种一体应用的开发。
- 2.易于部署——只需要将 WAR 文件或目录结构放到合适的运行环境下即可。
- 3.易于伸缩——只需要在负载均衡器下面运行应用的多份副本就可以伸缩。
缺点：
- 1.代码库庞大——代码库的体积越来越大，新人来到团队会有恐惧感。应用也变得越来越难于理解和修改，开发效率降低。模块化也随着时间变化慢慢被破坏。因为难于理解如何实现变更，代码质量也会逐渐下降。这就成了个恶性循环！
- 2.IDE 超载——代码体积越大，IDE 越慢，开发效率越低。
- 3.Web 容器超载——应用越大，容器启动时间越长。开发者大量的时间浪费在等待容器的启动上。这也会影响到部署。
- 4.难于持续部署——对于频繁部署，巨大的单体架构也是个问题。
- 5.难于伸缩应用——单体应用只能在一个维度伸缩，不能独立地伸缩各个组件。
- 6.难于调整开发规模——单体应用对调整开发规模也是个障碍。它会阻碍组织团队相互独立的工作。
- 7.需要对一个技术栈长期投入——单体架构迫使你采用开发初期选择的技术栈，如果要采用新的平台框架，需要重写整个应用，这样就太冒险了。
2. 微服务架构的优点和缺点
微服务架构的诞生正是解决单体架构的缺点。一个微服务架构的应用是多层架构的或是六角架构的，并且包含多种类型的组件：
- 1.表示组件——响应处理 HTTP 请求，并返回 HTML 或 JSON 或 XML。
- 2.业务逻辑——应用的业务逻辑。
- 3.数据库访问逻辑——数据访问对象用于访问数据库。
- 4.应用集成逻辑——消息层。
这些逻辑组件分别响应应用中不同的功能模块。
优点： - 1.每个微服务都相对较小。易于开发者理解；IDE 反应更快；Web 容器启动更快。
- 2.每个服务都可以独立部署，易于频繁部署新版本的服务。
- 3.易于伸缩开发组织结构。每个团队可以独立于其它团队开发、部署和伸缩服务。
- 4.提升故障隔离。一个服务出现故障，只有该服务受影响。
- 5.每个服务可以单独开发和部署。
- 6.消除了任何技术栈的长期投入。
缺点： - 1.开发者要处理分布式系统的额外复杂度。
- 2.测试更加困难。
- 3.开发者需要实现服务间通信机制。
- 4.不使用分布式事务实现跨服务的用例更加困难。
- 5.实现跨服务的用例需要团队间的细致协作。
- 6.生产环境的部署复杂度高，对于包含多种服务类型的系统，部署和管理的操作复杂度仍然存在。
- 7.内存消耗增加。
三、何时采用 MSA
微服务使开发变得更简单、更快捷了。但是，微服务带来一系列的非功能性需求，比如说事务、服务治理（注册，发现，负载，路由，认证授权，隔离）、监控（日志，性能监控，告警，调用链路）、部署、测试等。微服务依赖于“基础设施自动化”。
