下载掌阅APP，畅读海量书库
立即打开
正向治理是通过相应的治理手段，解决微服务改造后带来的一系列问题，接下来围绕效率、稳定性和效果方面的治理工作展开讨论。
效率包括的范围很广，具体包括开发效率、测试效率、运维效率等。开发效率一般通过采用微服务框架的方式解决，运维效率放到稳定性治理里面讨论，接下来主要讨论测试效率相关的治理，包括测试环境构造，以及测试数据的获取。
1.基于流量录制和回放的测试
微服务化架构下，微服务自身依赖的第三方服务、数据越来越多，给传统的测试方式带来很多困难，如被依赖的线下服务不稳定；服务无法提供期望的响应数据；缺少测试场景构造标准等。针对这些问题，一般能想到的思路是提高测试环境稳定性、自己构造测试数据和测试场景等方式，提高测试的确定性和有效性，但这些方式不能从根本上解决问题。比如，服务不稳定的情况仍然无法避免，通过更改代码注入对象等方式不仅繁杂而且非常容易出错，并且没有一定的依据，构造的测试场景不充分，心里没底。
上述问题导致了代码质量下降、自测/测试困难，在业务越来越复杂，依赖服务越来越多的大环境下，这些问题变得越加严重，到了必须要升级解决方案的地步。
针对上述微服务测试的不足，尝试推出了流量录制和回放解决方案，通过一定的方式将线上的真实流量录制下来，在线下进行回放。线下测试时，基于线上的回放流量可以灵活地测试服务的各自功能，还可以基于回放流量进行编辑修改，对服务依赖的第三方请求进行mock和定制，使代码开发变得简单方便，且可随改随测，解决RD开发不便、自测流程过长的问题。
录制的流量要包含服务的请求/返回流量，以及能关联上的与其对应的第三方交互流量。如果仅有服务的请求/返回流量，则只能被应用在查询类只读系统中，应用范围受限；如果第三方交互不能和请求正确关联，则无法正确应用这些流量。
要解决流量的关联难题，一个解决方案是将流量整流，使其串行化。将线上原本服务并行流量的一台机器，控制其接收到的流量，将其服务的流量降低至串行，且流量之间间隔一定的时间（以便给异步第三方请求预留时间），那么这些流量的请求/响应和其第三方交互流量就被自动地关联了起来。
还有一个难题是如何将请求和第三方交互流量关联起来，这块其实没有一个特别通用的解决方案，可以基于分布式跟踪技术将请求和对第三方系统调用的流量关联起来。但这种方式难点是并非所有第三方交互流量都带有请求跟踪标识。还有一种思路是通过拦截语言层面的系统调用，将请求和对第三方系统的调用进行关联。
2.基于仿真环境的测试
作为在线服务，为了满足灰度发布、测试等多维度的需求，一般需要支持灵活的分流策略，将流量调度到不同的环境中。
为了支持精细的灰度发布策略，需要根据一定的规则将线上流量分流到小流量集群，为了支持使用真实流量进行高仿真测试，还需要根据策略规则将一定流量引到仿真环境中。小流量分流的特点是流量发往小流量集群后，不再进行任何处理，直接等待小流量集群的返回结果，然后将该结果转发给调用侧。仿真环境分流的特点是发往仿真环境的流量只是一份“影子”流量，相当于Oneway请求（不需要应答消息），对业务处理过程没有任何影响，还是和没有仿真环境的情况下一样处理。
仿真环境支持可以在服务框架层面进行，为了实现基于请求内容的路由和转发，框架充当了一个Proxy的角色，将请求解析后再发包发送给下游环境。
基于仿真流量的特点，为了不对业务产生影响，发送到下游仿真环境的超时时间可以设置得非常小，即使有一些流量超时也没有关系，同时为了在自动生成的代码框架下实现仿真环境处理后的Oneway效果，可以自定义一个传输层，这个传输层的具体实现是什么都不进行处理，直接丢弃即可。
稳定性治理是服务治理的重中之重，下面重点讨论稳定性治理的体系和模型。
1.稳定性治理模型
稳定性治理是一个对故障进行管理的过程。从故障管理的视角看，可以分为故障预防、故障发现、故障定位、故障止损以及故障恢复5个阶段，稳定性建设的各项工作融入故障模型的各个阶段。如果将稳定性故障和火灾进行类比，稳定性工作模型实际上是一个防火–放火–灭火模型。所谓防火，就是通过各种机制和措施，提前排查出系统中各种可能的隐患，防止灾难的发生；灭火是指实际发生了问题，就要最大限度地进行止损，减少灾难的影响面，尽快恢复业务的正常运行；放火类似于消防演习，定期模拟灾难的发生，并制定相应的疏散通道，通过演习可以排查出当前仍然有哪些待改进的地方。比如，消防意识不够，疏散通道设计不太合理等，通过不断的周期性演习和针对性改进，可以提高大家在面对真实火灾的应对速度和处理能力，可以对实际的灾难的控制有很好的参考价值，演习尽可能有一定的逼真度，如果只是例行的走个过场，不会收到太大的效果。
从各阶段的抓手上看，故障预防包括稳定性设计、风险度量分析体系以及变更管理这几个环节，分别从服务设计、风险检测和分析及变更拦截这几个维度，在研发生命周期的不同环节对故障进行多级拦截。
服务上线后需要有相应的机制能够检测当前系统是否正常工作，当系统不正常时有相应的控制措施，因此从故障发现、定位和止损上，需要有一连串的基础设施支持，保证系统可见、故障可发现可定位、可控制。
2.基于容器化的稳定性治理
微服务在开发、测试、运维、容量成本等方面带来了诸多难题，容器技术的使用可以很大程度上缓解微服务架构所带来的问题。将容器技术和微服务架构结合，从开发、测试到上线，实现了“一次编写，到处运行”。
容器的最有革命性的创新是 镜像技术 ，它将应用程序、基础库和环境等封装在一起，作为微服务封装和运行的基石。轻量级的镜像技术作为微服务的交付方式，从如下几个方面极大地影响和改变了微服务生态体系。
物理机环境下，如果直接基于裸机，那么环境搭建的开销很大，并且很难保证不同环境的一致性。虚拟机环境下，虽然也引入了镜像，但镜像特别大，一般都是几十GB，甚至上百GB，很难快速创建和迁移。容器环境下，由于镜像比较轻量，每次变更后，可以快速创建本次变更对应的镜像，同时可以基于本次镜像快速创建多个完全相同的测试环境，容器镜像封装了所有运行应用程序所必需的相关细节，比如应用依赖以及操作系统。这就使得镜像从一个环境移植到另外一个环境更加灵活，有力地支撑了微服务快速迭代场景下的测试。
微服务架构下微服务个数比较多，并且每个服务的变更非常频繁，运维的工作量很大，借助容器镜像，可以把环境交付提前。每个研发多付出5%的工作量，换取运维200%的工作量，可以加速微服务变更的快速部署和落地。
微服务架构下流量变化很快，遇到突发大流量时，如果系统具备快速便捷的扩容/缩容能力，可以极大地提高系统的稳定性和灵活性。我们可以借助容器技术，快速构建完善的扩缩容基础设施，流量峰值时快速扩容，流量低峰时缩容。
微服务的云化架构，在运维层面和之前会有很大的差异，基础设施层面，比如部署系统、配置系统、监控系统等都需要针对上云进行相应的适配调整，服务云化过程中也会遇到很多特有的问题，下面会梳理下之前微服务云化过程中实际过程中遇到的一些典型问题，以便给后续的微服务云化落地一些帮助。
之前的微服务云化迁移是直接从物理机迁移到Kubernetes容器集群，迁移一般是一个服务一个服务逐渐迁移的，如果Kubernetes集群和原来物理机集群通信上完全不互通，会使服务迁移前后在部署上有很多的改动。比如以服务间调用来说，之前是集群内部的调用，迁移期间需要修改为以Kubernetes Ingress的方式进行调用，但整个物理机集群都被迁移到Kubernetes集群后，在Kubernetes网络中，又需要改回到集群内部调用的方式。从终态看，整个迁移过程中做了很多无用的工作。
为了减少Kubernetes容器化改造过程中频繁的调用方式改动，我们在迁移过程中遵循一个重要的原则，迁移前后网络互通，这样迁移过程中调用方式不需要有任何变化，迁移过程中业务完全不需要感知。
云化架构下，虽然使用上和之前没有明显的差异，但毕竟是两个完全不同的环境，在物理机上验证完全没有问题，不代表容器环境下也可以正常工作。之前遇到过一个问题，服务之前运行完全正常，迁移到云化架构下一段时间后，由于日志被错误地输出到了内存型文件系统中，内存被一点点耗尽，由于没有完善的线上监控，引发线上故障；导致问题的具体原因是物理机日志组件使用了字符设备，容器环境下虽然在宿主机下也配置了对应的字符设备，但并未为宿主机下的容器单独创建，因此云化迁移过程中，应该对容器和物理机环境上的一些差异有着清醒的认识。
容器环境下，各种服务混部，当某个容器消耗的资源超过一定限度时，如果没有完善的资源隔离机制，就会导致同一宿主机上的其他服务异常。精细化的资源隔离技术是容器技术大规模推广的一个必要前提。
服务上云毕竟是个全新的环境，可能会遇到各种类型的问题，特别是网络层面，从硬件网络过渡到软件定义网络（SDN），虽然灵活性比之前大大加强，但SDN网络在成熟度和稳定性上比之前的硬件网络还有不小的差异。之前遇到过一次SDN网络异常，导致整个机房的容器服务不可用，幸好当时有多机房流量切换预案，才没有导致更大的问题。因此服务上云前，需要提前想到有哪些可能的故障类型，针对每种故障设置相应的容灾预案。