微服务架构

2017-04-05 23:37:00

微服务一词越来越火爆，不谈微服务仿佛就 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.需要对一个技术栈长期投入——单体架构迫使你采用开发初期选择的技术栈，如果要采用新的平台框架，需要重写整个应用，这样就太冒险了。