从0开始学架构_37_36_微服务架构最佳实践_-_基础设施篇
你好，我是华仔。
今天我和你分享的主题是微服务架构、最佳实践基础设施篇。
每项微服务基础设施都是一个平台，一个系统、一个解决方案。
如果要自己实现其过程和作业务系统类似，都需要经过需求分析、架构设计、开发、测试、部署、上线等步骤。
专栏里我来简单介绍一下每个基础设施的主要作用。
更多详细设计。
你可以参考spring cloud的相关资料，下面进入今天的内容微负架构、最佳实践的基础设施篇一、自动化测试。
微服务将原本大一统的系统拆分为多个独立运行的微服务，微服务之间的接口数量大大增加，并且微服务提倡快速交付版本周期短，版本更新频繁，如果每次更新都靠人工回归，整个系统，则工作量大、效率低下，达不到快速交付的目的。
因此，必须通过自动化测试系统来完成绝大部分测试回归的工作。
自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试系统间的接口测试。
理想情况是每类测试都自动化。
如果因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试、自动化。
二、自动化部署相比大一统的系统，微服务需要部署的节点增加了几倍甚至十几倍，微服务部署的频率也会大幅提升。
综合计算下来，微服务部署的次数是大一统系统部署次数的几十倍。
这么大量的部署操作，如果继续采用人工手工处理，需要投入大量的人力，且容易出错，因此需要自动化部署的系统来完成部署操作。
自动化部署系统包括版本管理、资源管理部署操作、回退操作等功能。
三、配置中心微服务的节点数量非常多，通过人工登录，每台机器手工修改效率低，容易出错，特别是在部署或者排账时，需要快速增删改查配置，人工操作的方式显然是不行的。
除此之外，有的运行器配置需要动态修改，并且所有节点及时生效，人工操作是无法做到的。
综合上面的分析，微服务需要一个统一的配置中心来管理。
所有微服务节点的配置配置中心，包括配置版本管理、增删改差、配置节点管理、配置同步配置推送等功能。
四、接口框架微服务提倡轻量级的通信方式，一般采用HTTP rest或者RPC方式，统一接口协议。
但在实践过程，中光统一接口协议还不够，还需要统一接口传递的数据格式。
例如，我们需要指定接口协议为HTTP rest.但这还不够，还需要指定HTTP rest的数据格式采用jason,并且jason的数据都遵循文稿中的规范。
如果我们只是简单指定了HTTP rest协议，而不指定jason和jason的数据规范，那么就会出现这样混乱的情况。
有的微服务采用XML,有的采用jason,有的采用建制队，即使同样都是jason, jason数据格式也不一样。
这样每个微服务都要适配几套，甚至几十套接口协议，相当于把曾经由ESB做的事情转交给微服务自己做了。
这样做的效率显然是无法接受的，因此需要统一接口框架。
接口框架不是一个可运行的系统，一般以库或者包的形式提供给所有微服务调用。
例如，针对上面的jason样例，可以由某个基础技术团队提供多种不同语言的解析包。
五API网关系统拆分为微服务后，内部的微服务之间是互联互通的，相互之间的访问都是点对点的。
如果外部系统想调用系统的某个功能，也采取点对点的方式，则外部系统会非常头大。
因为在外部系统看来，他不需要也没办法理解这么多微服务的职责分工和边界，他只会关注他需要的能力，而不会关注这个能力，应该由哪个微服务提供。
除此以外，外部系统访问系统还涉及安全和权限相关的限制。
如果外部系统直接访问某个微服务，则意味着每个微服务都要自己实现安全和权限的功能。
这样做不但工作量大，而且都是重复工作。
综合上面的分析，微服务需要一个统一的api网关，负责外部系统的访问操作。
Api网关是外部系统访问的接口，所有的外部系统接入系统都需要通过API网关，主要包括接入健全权限、控制传输加密请求、路由流量控制等功能。
六、服务发现微服务种类和数量很多。
如果这些信息全部通过手工配置的方式写入各个微服务节点。
首先配置工作量很大，配置文件可能要配几百上千行，几十个节点加起来后配置项就是几万几十万。
行了，人工维护这么大数量的配置项是一项灾难。
其次是微服务节点经常变化，可能是由于扩容导致节点增加，也可能是故障处理时隔离到一部分节点，还可能是采用灰度升级，先将一部分节点升级到新版本，然后让新老版本同时运行。
不管哪种情况，我们都希望节点的变化能够及时同步到所有其他依赖的微服务。
如果采用手工配置，是不可能做到实时更改生效的，因此需要一套服务发现的系统来支撑微服务的自动注册和发现服务。
发现主要有两种，实现方式，自理式和代理式。
第一种自理是字理式结构，请点击问告查看自理式结构，就是指每个微服务自己完成服务发现。
例如，图中service instance a访问service regisry获取服务注册信息，然后后直接问service instance. B自自理式服务发现实现比较简单。
因为这部分的功能一般通过统一的程序库或者程序包提供给各个微服务功用，并且每个微服服务都自己重重复现现一，并且由由每每微服务务承承担的服务发现的功能，访问压力分散到了各个微服务节点，性能可用性上，不存在明显的压力和风险。
第二种，代理式代理式结构请点击文稿查看。
代理式结构就是指微服务之间有一个负载均衡系统由负载均衡系统来完成。
微服务之间的服务发现，代理式的方式看起来更加清晰，微服务本身的实现也简单了很多，但实际上这个方案风险较大。
第一个风险是可用性风险，一旦load balance er系统故障就会影响所有微服务之间的调用。
第二个风险是性能风险。
所有的微服务之间的调用流量都要经过load balancer系统，性能压力会随着微服务数量和流量增加而不断增加，最后成为性能瓶颈。
因此，load balancer系统需要设计成集群的模式，但load balancer集群的实现本身又增加了复杂性，不管是自理式还是代理式，服务发现的核心功能就是服务注册表。
注册表记录了所有的服务节点的配置和状态。
每个微服务启动后，都需要将自己的信息注册到服务注册表，然后由微服务或者load balance er系统到服务注册表查询，可用服务七服务路由。
有了服务发现后，微服务之间能够方便的获取相关配置信息。
但具体进行某次调用请求时，我们还需要从所有符合条件的可用微服务节点中挑选出一个具体的节点发起请求，这就是服务路由需要完成的功能。
服务路由和服务发现紧密相关。
服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。
对于自理式服务，发现服务路由是微服务内部实现的。
对于代理式服务，发现服务路由是由load balancer系统实现的。
无论放在哪里，实现服务路由核心的功能就是路由算法。
常见的路由算法有随机路由、轮询路由、最小压力路由、最小连接数路由等。
八、服务容错系统拆分为微服务后，单个微服务故障的概率变小，故障影响范围也减少，但是微服务的节点数量大大增加。
从整体上来看，系统中某个微服务出故障的概率会大大增加。
专栏第三十四期，我在分析微服务陷阱时提到微服务具有故障扩散的特点，如果不及时处理故障故障扩散开来，就会导致看起来系统中很多服务节点都故障了。
因此需要微服务能够自动应对这种出错场景，及时进行处理。
否则，如果节点一故障，就需要人工处理，投入人力大，处理速度慢，而一旦处理速度慢，则故障就很快扩散。
所以我们需要服务容错的能力，常见的服务容错包括请求重试、流控和服务隔离。
通常情况下，服务容错会集成在服务发现和服务路由系统。
中九服务监控系统拆分为微服务后节点数量大大增加，导致需要监控的机器网络进程接口调用数等监控对象的数量大大增加。
同时，一旦发生故障，我们需要快速根据各类信息来定位故障。
这两个目标如果靠人力去完成是不现实的。
举个简单例子，我们收到用户投诉，说业务有问题。
比如此时采取人工的方式去搜集分析信息，可能把几十个节点的日志打开一遍，就需要十几分钟了。
因此，需要服务监控系统来完成微服务节点的监控，服务监控的主要作用有实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间。
服务监控可以在实时分析的基础上进行预警。
在问题萌芽的阶段，发掘并预警，降低了问题影响的范围和时间。
通常情况下，服务监控需要搜集并分析大量的数据，因此建议做成独立的系统，而不要集成到服务发现API网关等系统中。
十、服务跟踪服务监控可以做到微服务节点级的监控和信息收集。
但如果我们需要跟踪某一个请求，在微服务中的完整路径，服务监控是难以实现的。
因为如果每个服务的完整请求链信息都实时发送给服务监控系统，数据量会大到无法处理服务监控和服务跟踪的区别，可以简单概括为宏观和微观的区别。
例如，a服务通过HT tp协议请求b服务十次。
B通过HTTP返回jason对象服务监控会记录请求次数、影响时间平均值，影响时间最高值、错误码分布这些信息。
而服务跟踪会记录其中某次请求的发起时间、响应时间、响应、错误码、请求参数返回的jason对象等信息。
目前，无论是分布式跟踪还是微服务的服务跟踪，绝大部分请求跟踪的实现技术都是基于谷歌的deaper论文。
十一服务安全系统拆分为微服务后数据分散在各个微服务节点上。
从系统连接的角度来说，任意微服务都可以访问所有其他微服务节点。
但从业务的角度来说，部分敏感数据或者操作只能部分微服务可以访问，而不是所有的微服务都可以访问。
因此，需要设计服务安全机制来保证业务微数据的安全性。
服务安全主要分为三部分，接入安全、数据安全传输安全通常情况下，服务安全可以集成到配置中心系统中进行，实现及配置中心配置微服务的接入安全策略和数据安全策略。
微服务节点从配置中心获取这些配置信息，然后再处理具体的微服务调用请求时，根据安全策略进行处理。
由于这些策略是通用的，一般会把策略封装成通用的库，提供给某个微服务，调用基本架构，请查看文稿。
今天我为你讲了微服务架构相关的基础设施的概要介绍和关键设计点，希望对你有所帮助。
这就是今天的全部内容。
这一期的思考题很特别，给你一个由十位java高级软件工程师组成的开发团队，采用自研的方式完成所有的微服务基础设置开发。
你预测需要多长时间？理由是什么呢？欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。