深入浅出 -- 系统架构之微服务标准组件及职责

我们来认识一下微服务架构在Java体系中依托哪些组件实现的。

相对于单体架构的简单粗暴，微服务的核心是将应用打散，形成多个独立提供的微服务，虽然从管理与逻辑上更符合业务需要。但微服务架构也带来了很多急需解决的核心问题：

1、如何发现新节点以及检查各节点的运行状态？

2、如何发现服务及负载均衡如何实现？

3、服务间如何进行消息通信？

4、如何对使用者暴露服务API？

5、如何集中管理各节点配置文件？

6、如何收集各节点日志并统一管理？

7、如何直观的了解各节点间的调用链路？

8、如何对系统进行链路保护，避免服务雪崩？

可以发现，以上的各个问题，不是针对某种语言或某种技术的，任何要构建微服务架构的企业都需要面对这些问题，要么公司内部逐个研究各个问题的解决办法，要么就将已有的多种技术整合形成整体解决方案。好在经过互联网行业的多年发展，业内对于上述问题基本都有了标准的解决方案，下图清晰的说明了微服务架构需要的标准组件。

下面我们来逐个了解各个组件的职责：

1、注册中心（Service Registry）

注册中心是微服务架构最核心的组件。它起到的作用是对新节点的注册与状态维护，通过注册中心可解决上述第1个问题（1、如何发现新节点以及检查各节点的运行状态？ ）。

微服务节点在启动时会将自己的服务名称、IP、端口等信息在注册中心登记，注册中心会定时检查该节点的运行状态。注册中心通常会采用心跳机制最大程度保证已登记过的服务节点都是可用的。

2、负载均衡（Load Balance）

负载均衡解决了第2个问题（ 2、如何发现服务及负载均衡如何实现？ ）。通常微服务在互相调用时，并不是直接通过IP、端口进行访问调用。而是先通过服务名在注册中心查询该服务拥有哪些节点，注册中心将该服务可用节点列表返回给服务调用者，这个过程叫服务发现，因服务高可用的要求，服务调用者会接收到多个节点，必须要从中进行选择。因此服务调用者一端必须内置负载均衡器，通过负载均衡策略选择合适的节点发起实质性的通信请求。

3、服务通信(Communication)

服务通信组件解决了问题3（3、服务间如何进行消息通信？ ）。服务间通信采用轻量级协议，通常是HTTP RESTful风格。但因为RESTful风格过于灵活，必须加以约束，通常应用时对其封装。例如在SpringCloud中就提供了Feign和RestTemplate两种技术屏蔽底层的实现细节，所有开发者都是基于封装后统一的SDK进行开发，有利于团队间的相互合作。

4、API服务网关(API Gateway)

服务网关主要是解决问题4（4、如何对使用者暴露服务API？ ），对于最终调用方来说，微服务的通信与各种实现细节应该是透明的，调用者只需关注他要使用的 API 接口即可。因此微服务架构引入的服务网关控制用户的访问权限。服务网关是外部环境访问内部微服务的唯一途径，在这个基础上还可以扩展出其他功能，例如：用户认证与授权、容错限流、动态路由、A/B测试、灰度发布等。

微服务API网关

5、配置中心(Config Management)

配置中心主要解决了问题5（5、如何集中管理各节点配置文件？ ），在微服务架构下，所有的微服务节点都包含自己的各种配置文件，如jdbc配置、自定义配置、环境配置、运行参数配置等。要知道有的微服务可能可能有几十个节点，如果将这些配置文件分散存储在节点上，发生配置更改就需要逐个节点调整，将给运维人员带来巨大的压力。配置中心便由此而生，通过部署配置中心服务器，将各节点配置文件从服务中剥离，集中转存到配置中心。一般配置中心都有UI界面，方便实现大规模集群配置调整。

重复的配置文件

配置中心集中管理配置文件

6、集中式日志管理(Centralized Logging)

集中式日志主要是解决了问题6（6、如何收集各节点日志并统一管理？ ）。微服务架构默认将应用日志分别保存在部署节点上，当需要对日志数据和操作数据进行数据分析和数据统计时，必须收集所有节点的日志数据。那么怎么高效收集所有节点的日志数据呢？业内常见的方案有ELK、EFK。通过搭建独立的日志收集系统，定时抓取各节点增量日志形成有效的统计报表，为统计和分析提供数据支撑。