目录
[2.1 概述](#2.1 概述)
[2.2 微服务需要支持的基础功能](#2.2 微服务需要支持的基础功能)
[2.2.1 业务服务的脚手架](#2.2.1 业务服务的脚手架)
[2.2.2 微服务通信](#2.2.2 微服务通信)
[2.2.3 集成公司内的其他基础设施](#2.2.3 集成公司内的其他基础设施)
[2.2.4 微服务治理支持](#2.2.4 微服务治理支持)
[2.3 微服务框架的选型考虑](#2.3 微服务框架的选型考虑)
[2.3.1 概述](#2.3.1 概述)
[2.3.2 稳定性](#2.3.2 稳定性)
[2.3.3 易用性](#2.3.3 易用性)
[2.3.4 调试与运维友好性](#2.3.4 调试与运维友好性)
[2.3.5 功能和性能](#2.3.5 功能和性能)
[2.4 微服务改造时的语言选型考虑](#2.4 微服务改造时的语言选型考虑)
[3.1 接口标准化](#3.1 接口标准化)
[3.2 日志标准化](#3.2 日志标准化)
[3.3 透传通道标准化](#3.3 透传通道标准化)
[4.1 概述](#4.1 概述)
[4.2 研发全流程平台](#4.2 研发全流程平台)
[4.3 灰度发布](#4.3 灰度发布)
一、概述
微服务改造是个综合性的系统工程，涉及研发全流程的各个维度，因此在微服务实施前需要进行一些必要的准备工作，比如从团队、技术上进行一系列的储备，确保微服务实施可以稳步进行。下面重点从微服务开发框架、微服务标准化以及持续集成和发布这几个维度分析微服务开展前的一些准备工作。
二、微服务开发框架
2.1 概述
微服务背景下，微服务通信越来越复杂，通信场景和通信方式越来越多。一个运行良好的服务，不仅需要完成必需的功能需求，还要关注性能、稳定性、健壮性、兼容性、扩展性等诸多方面，此外还有日志、监控、统计、安全、容灾、容错等。从上面的需求来看，写一个完善的服务需要考虑的因素太多，特别是在移动互联网这种需求多变、对项目开发迭代速度和开发效率要求特别高的场景下，工程师很难在很短的时间考虑这么全面，写出符合预期的高性能高可用服务。
绝大多数服务对非功能特性和服务治理的需求都有一定的相似性，因此如果能够将功能需求之外的部分从业务中剥离，通用的、业务无关的特性对业务人员透明，那么业务人员只需要将精力聚焦在业务逻辑上，就可以快速完成微服务的开发。
微服务开发框架就是为了实现上述需求而产生的，聚焦和业务逻辑关系不太大的非功能需求，提高微服务开发效率，同时更为重要的是，使用相同的服务框架，业务服务可以更容易地实现服务标准化。
2.2 微服务需要支持的基础功能
通常情况下，一个成熟完善的服务治理框架，基本功能层面需要包含如下几个部分。
2.2.1 业务服务的脚手架
业务服务的脚手架是指在不考虑和其他服务通信的情况下，如何快速搭建一个业务服务。微服务架构下，需要从头快速创建微服务的场景很多，很多服务，尤其是在线服务，除了业务相关的处理逻辑之外，服务启动、服务退出、服务请求处理等流程几乎类似，至少可以针对绝大多数场景，抽象出一些通用的模式来。同时业务服务都会使用一些通用的基础组件，如日志库、配置库等，这些基础组件每个服务都会需要，因此对组件的性能、稳定性都有很高的要求。
2.2.2 微服务通信
微服务通信包含的东西很多，如网络模型、服务发现、流量路由、负载均衡、连接池管理等。
2.2.3 集成公司内的其他基础设施
很多公司都会有一些自研或者在开源基础上二次开发的基础设施，比如各种中间件产品、配置中心、部署平台、监控平台等，服务开发框架很重要的一个作用是和这些内部基础设施进行集成，对微服务业务人员屏蔽这些基础设施的细节。特别是一些中大型公司基础设施体系在实现上差异很大，从而很难直接使用开源的微服务开发框架，一般采用自研或者在开源基础上进行二次开发。
2.2.4 微服务治理支持
系统经过微服务改造后，在效率、稳定性等环节都会遇到不少新的挑战，需要完善的服务治理支持，这些服务治理一般也是以微服务开发框架为支撑或者抓手的。服务治理是个很大的话题，放在第2章中专门讨论，这里不再展开。
2.3 微服务框架的选型考虑
2.3.1 概述
选择和评估一个微服务开发框架时，应该从稳定性、易用性、调试与运维友好性这几个维度来考量。
2.3.2 稳定性
稳定性和可靠性是第一位的，如果代码质量不高，经常出现一些不太好解释的现象，这样肯定会影响线上服务的可用性。
2.3.3 易用性
首先API接口设计要非常简洁明确，没有什么歧义，使用起来非常方便，没有什么大的心智负担。对于一些配置项框架要设置最合理的默认值，如果一个框架有非常多的配置参数，并且都交给用户，美其名曰是给用户灵活性，其实是把复杂和负担留给用户，把简单留给自己，这种框架是极其不负责任的。
2.3.4 调试与运维友好性
调试与运维友好性常常被市面上的大多数微服务开发框架所忽略，很多框架经常号称自己有强大的性能表现，但很少有框架在调试和运维上下工夫，如何让使用框架的人在遇到问题时方便快捷地定位，如何支持业务自定义地添加调试和定位信息，这些都是框架需要考虑的问题。
2.3.5 功能和性能
最后要考虑功能和性能，功能和性能要能够满足当前业务需求。
把这个放在最后是因为绝大多数框架在功能和性能上均能够满足需求。
对于性能评估和性能测试，大家平常一般主要关注QPS和耗时这两块。需要强调的是，性能测试前需要确定性能测试的基准，比如99.9%的响应时间必须在10ms之内。后续所有的性能测试需要严格按照这个基准执行。
针对QPS需要关注框架在多核或多线程下的扩展性；针对耗时，不仅要关注平均耗时，更要观察耗时长尾分布，以及耗时长尾是否有放大效应。
2.4 微服务改造时的语言选型考虑
不少人在进行微服务改造时，经常会有这样的疑问和想法：是否有必要在微服务化的同时选择更合适的语言？比如之前是PHP，微服务改造时想用Golang进行重构，这样是否可行？每种语言背后都有一套完善的语言栈体系，语言栈切换过程中很容易踩到一些坑，同时微服务改造本身也是一个复杂度很高的过程，如果把微服务改造和语言切换这两个风险很高的事情放在一起进行，会导致整个微服务改造过程中的风险增加很多，当过程中出现问题时也很难排查和控制。因此除非有特别的原因，不建议在微服务改造的时候进行语言层面的整体切换和重构，当然个别相对独立且风险可控的子服务，可以考虑语言层面的重构。
三、微服务标准化
3.1 接口标准化
接口标准化在微服务架构设计过程中发挥着重要的作用。在微服务的交互中，统一规范的接口标准可以大大减少沟通成本，提高开发和维护效率。
很多公司主流协议为HTTP协议和Protobuf/Thrift协议，HTTP协议开发、测试比较方便，而Protobuf/Thrift等二进制协议性能更好些。一般来说，和端交互比较多的业务服务使用HTTP协议较多，对性能有一定要求的后台基础服务偏向使用二进制协议。
以Thrift协议来说，Thrift协议本身有自己的一套IDL，通过IDL生成标准服务代码，包含数据通路和类型定义，相对规范；为了保持微服务接口层面的一致性，实现微服务接口标准化，HTTP协议可以参考Thrift协议的思路，增加IDL描述支持。HTTP服务的IDL化可以规范标准、降低人为操作的出错率、降低下游服务接入成本和维护成本。下游服务不需要再维护代码，只需要维护配置，这点对于尚未使用统一的服务治理框架的团队来说特别有益。下游服务的升级修改收敛于单纯的IDL文件，版本更好管理。
我们可以基于接口标准化，为接口增加相应的描述信息，并通过代码自动生成机制，将IDL文件直接生成接口文档，实现接口文档标准化。
为了减少业务对服务治理支持的开销，可以把服务治理相关的配置放到IDL文件，实现服务治理配置的代码化。
因此，IDL文件成为服务标准化中非常重要的一个载体，通过IDL文件可以实现接口标准化、文档标准化和服务治理标准化。
3.2 日志标准化
日志标准化是服务标准化的关键一环，各个微服务之间只有遵循相同的日志规范，才能方便后续的日志治理，针对Log、Trace等日志形态，均需要制定统一的规范。
日志输出的目的不仅是发现问题，好的日志可以帮助我们快速排查出问题的原因，进而采取相应的应对措施，因此日志规范需要聚焦如何更加方便快捷地追查问题，提高问题追查的效率。
3.3 透传通道标准化
为了对微服务进行精细化的治理和管控，很多服务治理特性均需要在同一请求处理的各个环节获取到请求相关的服务治理信息，因此系统需要能够支持服务治理相关的信息在请求处理的整个链路中透传，服务治理聚焦的都是非功能需求，这些需求业务服务其实是不需要关注的，因此需要有一定的机制来减少服务治理的非功能特性对业务的侵入，最大程度上实现业务透明的服务治理接入。
透传通道就是为了实现上述所说的服务治理透明接入，思路是将服务治理相关的非功能需求信息从业务中解耦出来，在所有微服务之间进行传递。
透传通道承载业务无关的服务治理信息传递，是业务微服务和服务治理基础设施的桥梁，关系到整个服务治理的效率和效果，因此需要有标准化的透传通道，实现通道数据传输的可靠、透明和可扩展。
四、持续集成与发布
4.1 概述
微服务改造过程中，需要保证改造过程中的修改及时得到验证，因此需要在持续集成和发布方面进行提前准备，确保微服务改造能够正常迭代进行。
4.2 研发全流程平台
微服务研发全流程包括很多环节，比如代码分支管理、代码review、测试准入、提测、自动化测试、服务部署、服务变更等，每个环节都有相应的工作流，研发工作流平台将研发全流程中的工作流串在一起，形成一个完整的闭环。这不仅可以提供特性研发工作的质量和规范度，还可以基于完整闭环机制方便地对每个特性的线上效果进行复盘和总结，通过微服务数字化运营，提高业务的迭代效率。
4.3 灰度发布
微服务化在架构层面是一个非常大的改动，为了不影响线上业务的稳定性，需要采用灰度发布的方式，每一次发布均需要先进行小范围灰度，观察完全没有问题之后再放量发布。
灰度发布的维度可以根据业务的特点而定，常见的灰度维度有按照机器、按照流量百分比、按照城市或者人群等。
为了支持精细化灰度发布，微服务改造前需要对部署系统进行适配升级，保证微服务化过程的每一步都精确可控，将对线上服务的影响降到最低。
好了，本次内容就分享到这，欢迎大家关注《微服务架构》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！