微服务架构的基础设施

一：服务发现

在现代基于云的微服务应用程序中，具有动态性。服务实例具有动态分配的网络位置。由于自动扩展、故障、升级，服务实例集会动态更改。因此客户端需要使用服务发现。

服务发现的概念：

其关键组件是服务注册表，它是包含服务实例网络位置信息的一个数据库。服务启动或停止时，服务发现机制会更新服务注册表。当客户端调用服务时，服务发现机制会查询服务注册表以获取服务实例的列表，并将请求路由到其中一个服务实例。

实现服务有以下两种方式：

1：服务端与客户端直接与服务注册表交互（应用层服务发现模式） 例如：consul

实现服务发现的一种方法是应用程序的服务及其客户端与服务注册表进行交互。下图。服务实例使用服务注册表注册其网络位置。客户端先通过查询服务注册表获取服务实例列表来调用服务，然后它向其中一个实例发送请求。

2：通过平台基础设施来处理服务发现（平台层服务发现模式） 例如：Docker、kubernetes

Kubernetes都具有内置的服务注册表和服务发现机制。部署平台为每个服务提供DNS名称，虚拟IP和解析VIP地址的DNS名称。客户端像DNS名称和VIP发出请求，部署平台自动将请求路由到其中一个可用服务实例。因此服务注册、服务发现和请求路由完全由部署平台处理。下图展示了它的工作原理

二：熔断、降级、容错与健康检查

分布式系统中，随时随地都可能会出现异常,我们需要尽可能地提高系统容错能力。容错，字面意思就是可以容下错误，不让错误再次扩张，让这个错误产生的影响在一定范围之内。我们常见的降级，限流，熔断器，超时重试等等都是容错的方法。服务降级通常指业务上的降级，比如淘宝双十一为了承受巨大的流量会暂时关闭退款功能。当然熔断也是属于服务降级的一种策略，当一个服务出现了故障，直接熔断这个服务，而不是等待调用超时。

断路器核心思想是监控客户端发出请求的成功和失败数量，如果失败的比例超过一定次数，就启动断路器，让后续的调用立刻失效。

一般的微服务架构通常都是使用Hystrix 断路器。

三：配置中心

微服务的节点数量非常多，通过人工登录每台机器手工修改，效率低，容易出错。特别是在部署或者排除故障时，需要快速增删改查配置，人工操作的方式显然是不行的。而且管理起来很散乱，所以引入了配置中心的概念，统一管理，配置中心本身也是单独了服务，客户端需要使用，通过传递参数来使用！配置中心在微服务架构中是很基础的组件，但也是不可缺少的一环

四：日志收集|服务监控

系统拆分为微服务后，节点数量大大增加，导致需要监控的机器、网络、进程、接口调用数等监控对象的数量大大增加；同时，一旦发生故障，我们需要快速根据各类信息来定位故障。在微服务架构中，每个服务的log都分散在不同的服务日志中，这样需要查看log非常不方便，所以把微服务中的log都收集到一起！方便排查！

Kubernetes 中比较流行的日志收集解决方案是 Elasticsearch、Fluentd 和 Kibana（EFK）技术栈，也是官方现在比较推荐的一种方案 

五：链路追踪

微服务系统中，客户端的一次请求，可能需要经过多个服务的相互协作才能完成。为了追踪客户端的一次操作背后调用了哪些模块以及调用先后顺序，我们需要一个分布式链路追踪系统。

六：自动化部署 DevOps

相比单体应用的系统，微服务需要部署的节点增加了几倍甚至十几倍，微服务部署的频率也会大幅提升，如果通过人工来操作的话，非常耗时，而且容易出错。持续交付和持续部署是DevOps的一部分，DevOps是一套快速、频繁、可靠的软件交付实践。高效的DevOps组织通常将软件部署到生产环境时面临更少的问题和故障。常用的DevOps工具有Docker、Kubernets、Jenkins、Git等

七：自动化测试

微服务将原本大的系统拆分为多个独立运行的“微”服务，微服务之间的接口数量大大增加，并且微服务提倡快速交付，版本周期短，版本更新频繁。如果每次更新都靠人工回归整个系统，则工作量大，效率低下，达不到“快速交付”的目的，因此必须通过自动化测试系统来完成绝大部分测试回归的工作。

自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试，理想情况是每类测试都自动化。如果因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试自动化。

八：接口框架

微服务提倡轻量级的通信方式，一般采用HTTP/REST或者GRPC方式统一接口协议。但在实践过程中，光统一接口协议还不够，还需要统一接口传递的数据格式。例如，我们需要指定接口协议为HTTP/REST，但这还不够，还需要指定HTTP/REST的数据格式采用JSON，并且JSON的数据都遵循如下规范。

九：服务安全

系统拆分为微服务后，数据分散在各个微服务节点上。从系统连接的角度来说，任意微服务都可以访问所有其他微服务节点；但从业务的角度来说，部分敏感数据或者操作，只能部分微服务可以访问，而不是所有的微服务都可以访问，因此需要设计服务安全机制来保证业务和数据的安全性。

服务安全主要分为三部分：接入安全、数据安全、传输安全。通常情况下，服务安全可以集成到配置中心系统中进行实现，即配置中心配置微服务的接入安全策略和数据安全策略，微服务节点从配置中心获取这些配置信息，然后在处理具体的微服务调用请求时根据安全策略进行处理。由于这些策略是通用的，一般会把策略封装成通用的库提供给各个微服务调用