《企业级容器云架构开发指南》—2.2.3　完整微服务系统包含的功能

2.2.3　完整微服务系统包含的功能

一个完整的微服务系统应该包含哪些功能？其实微服务的关键不仅仅是微服务本身，而是系统要提供一套基础架构，这种架构使得微服务可以独立地部署、运行、升级，不仅如此，这个系统架构还让各个微服务之间在结构上实现“松耦合”，在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面、统一的权限管理、统一的安全策略、统一的上线过程、统一的日志和审计方法、统一的调度方式、统一的访问入口等。

从图2-18我们可以看出，一个完整的微服务系统应该包括一个基座，要有日志和审计、监控和告警、消息（轻量级MQ或HTTP）、注册发现、负载均衡、事件调度，只有把这些基座都完成了，才可以在上面部署一个个的业务微服务。基座之上，我们要考虑外部和服务之间如何暴露API，外部请求只能通过服务网关来访问微服务，所有关于微服务相应的流控、安全、访问健全管理都会在这个网关上完成。

图2-18　完整的微服务所包含的功能

我们对外暴露了很多API，那么外部如何找到关于这些API的定义？API的每个动作都会有什么样的输入和输出？配合API网关，会有一个统一的文档框架，这个文档框架应该是开源的，也是一个工具集，大家可以不再去找拥有这些微服务的个人，而是直接找公司的主体，一般运营商都会对外有一个开放的门户，其中会定义对外开放了哪些能力，通过文档框架可找到开放了哪些能力。

一个基座、一个访问控制是整体微服务的根基。同时要有集成自动化、测试自动化、部署自动化，要有一个自动化流水线，这是为微服务团队的开发和集成部署服务的。另外，配合配置管理、代码管理、灰度发布，也要有相应的工具集。一般来讲，一个生产系统差不多会有3～4套环境，即一套开发环境、一套上线环境和一套对外真正的生产环境，有时还会有对外的性能测试环境。如果3～4套环境部署在不同的机房和不同的IDC里面，而每一次的配置如果是通过人工去完成的，那么为了一次性能测试，可以想象我们可能需要好几天时间来提前准备环境、测试和数据。但如果我们将配置预先写好，底层也是基于容器化的资源管理，那么为某一种测试建立一套环境就会简单很多，也无须用3～4天的时间预先准备一个环境，配置实际上主要是为了在这种多环境下实时部署。

无论是敏捷还是DevOps，我们认为最大的好处是上线和停机，7×24小时，一天做100个版本，但不能忽视其根本——灰度发布，我们必须先把环境进行分区，当想发布新版本的时候，会把请求路由到其中一个区，升级另外的分区，升级完成后再把请求升级到新分区，所以至少要有一个基本的灰度发布分区。总体来说，我们最终希望实现的完整的微服务系统需要先有一个框，然后再解构原来单体的功能，最后再部署微服务，这是一个有先后顺序的过程。