spring cloud系列(一) - 微服务架构介绍

什么是微服务架构？

微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。就是把因相同原因而变化的功能聚合到一起，而把因不同原因而变化的功能分离开，并利用轻量化机制（通常为HTTP RESTful API）实现通信。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

微服务架构 ≈ 模块化开发 + 分布式计算

---

微服务组件及概念

1. 服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
2. 服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
3. 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
4. 服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
5. 配置中心：将本地化的配置信息（properties, xml, yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
6. API管理：以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。
7. 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
8. 分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
9. 调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点
10. 支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过Docker等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

---

微服务架构的优势

1. 服务简单，只关注一个业务功能 ：单体架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。
   而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。
2. 松耦合：微服务架构抛弃了复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化。通过微服务架构可以更好的提升各个模块的可复用性和可组装性。通过微服务架构更好的实现了原单体应用内部各个组件或模块的彻底解耦，通过解耦本身也降低了原单体应用内部的复杂度。
3. 更容易水平扩展：微服务架构下实现了单体应用的垂直拆分，可以更加容易的通过廉价的X86服务器或docker服务器资源来实现水平扩展。
4. 敏捷开发与运维：采用微服务架构可以更好的实现DevOps开发运维一体化，同时因为微服务架构下各个微服务模块相对独立和松耦合，因此在后续业务变更的分析和处理中往往能够更加敏捷快速的响应，同时相对影响也最小。可以使研发过程根据敏捷和小团队化，包括和敏捷软件开发最佳实践更好的匹配，每个微服务模块都可以形成独立的敏捷小团队进行开发和部署上线
5. 更加自由化：各个微服务之间可以选择不技术实现，可以根据业务功能进行自由技术选型。

---

微服务架构的劣势

1. 分布式系统的复杂性：微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。
2. 分布式事物管理：由于各个微服务模块完全相对独立和松耦合，因此对于跨多模块业务带来的分布式事务问题是必须解决或找寻替代方案。特别是在微服务架构下数据库已经进行了垂直拆分，对于跨库访问本身的分布式事务一致性问题是最需要和重视的问题。
3. 隐式接口：服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。
4. 部署开销：由于微服务模块需要独立部署，往往涉及到多达上100个容器的安装和部署和集成等相关工作，这也是需要和Docker集成并实现自动部署的一个原因。
5. 运维开销：更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。
6. DevOps要求：使用微服务架构后，开发团队需要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。
7. 异步、测试面临挑战：跨进程之间的大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。
   总而言之，微服务架构有很多吸引人的地方，不过在拥抱微服务之前要认清它所带来的挑战。而每一种架构都有其优缺点，我们需要根据项目业务和团队情况来选择合适的架构。

---

微服务架构的使用场景

1. 规模大（团队超过10人）
2. 业务复杂度高（系统超过5个子模块）
3. 需要长期演进（项目开发和维护周期超过半年）

---

总结

单体式的架构更适合轻量级的简单应用。微服务架构模式可以用来构建复杂应用，当然，这种架构模型也有自己的缺点和挑战。