开发者学堂课程【微服务全生命周期稳定性实践 ：微服务全生命周期稳定性实践（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1205/detail/18172
微服务全生命周期稳定性实践
三、SOFA 微服务从开发到运维
第三个部分将从 SOFA 微服务从开发到运维介绍。它是蚂蚁科技这边从内部孵化出来的一套分布式金融级的中间件，它里面包括可以看底下这张图，它包括两个部分。
看左边的这幅图，里面是一个客户端和服务端，主要跟介绍一下 SOFA 的中间件他是怎么样去作用的。SOFA 客户端的部分就是指业务应用，就是包括自己平常业务开发。可以认为 spring boot ，sofar boot 就是基于 spring boot 去做的一个开发，它里面会有一些 SDK，这些 sdk 就负责和服务端的中间件去做通信。今天介绍的是更偏向于上层跟业务更接近的一些稳定性的实践，不涉及底层包括这种容器或者是更底层的一些 ass 层面的东西，就专注于说上层的业务要去怎么样去开发，要怎么样去使用中间件，要怎么样实践。刚才在前面讨论的全生命周期的这种稳定性的一个方案。比如在一开始在架构设计的阶段，就是要考虑到到底是要同步调用还是异步调用，如果是同步调用， SOFA 的中间件是 RPC 和 rest 的。 SOFA rpc 调用也是基于 SOFA 的注册中心，包括其他的一些开元的，包括 double 都是一个类似的作用类似的一个原理就是负责 rpc 调用的。另外也会有异步调用，它负责的中间件是比如任务调度，用时间作为一个出发点，或者是用一些事件作为一个出发点的，这种调度可能是消息队列，是对两个业务用消息队列去做一个解耦，此时在设计架构的就要考虑到这些。在微服务开发过程中，也会有一些像其它的这种消息队列 rocket q 之类的。另外会考虑到服务管控，这也是架构设计里面的一点，有没有这种动态配置的能力能够去动态的开关一些功能，或者说是下发一些配置去做这种模块的下线或者是隔离，去做一些熔断限流，这些措施都是通过动态配置去实现的。另外现在的这种分布式开发一定绕不开的一个话题，即当数据量越来越大的，要考虑是不是要做数据的拆分，如果要做分库分表，一定逃不开数据库访问代理的这么一个中间件组件，它能够帮屏蔽底层数据库的一些差异，能够让像写一个单库单表的一样去用它。分库分表的数据库当有这种情况和跨库的情况，一定逃不过一个问题就是分布式事务， SOFA 中间件也存在一些分布式事务的解决方案，包括两阶段提交的一些方案，以及说有阿萨的一些重整模式的一些方案，都是能够解决分布式事务的问题。
当考虑好整个架构是怎么去把几个微服务或者是几十个很多的微服务串联。不管是用同步的串联，还是用异步地串联，还是用其他的一些方式的串联能够组成整个一个大的业务业务系统的，日志是不能忽略的。在此可以简单的介绍一下日志在加工设计阶段，要考虑哪些内容，比如第一点是通用的，包括业务日志的文件的命名规范，日志的输出的级别的规范。他的滚动策略，滚动策略是指说以多长时间切分为一个日志文件，日志量不大的可以以天来区分，如果比较大的可以以小时来区分，但是不推荐以文件大小来区分，因为较为麻烦。还有日志清理策略，因为日志的清理策略会影响磁盘的稳定性，磁盘对于来说也是一个系统非常重要的指标。然后第二点是日志的设计，所谓日志的设计里面要考虑到说是要通过日志要得到一些什么东西，是对业务要达到什么目标，是不是业务的统计分析要用，比如银行一天有多少笔的转账，关键的一些处理节点的异常的感知，因为在开发的过程中经常会遇到一种情况，如果这里出问题，开发他在会想这里出问题，系统有没有能力自愈，但是有一些情况是一定要人为干预的，此时非常关键，因为这种关键节点的日志，一方面是给后续排查带来线索，另外一方面它能够结合监控感知到异常的节点之后，能够告诉我们，去及时的去人为介入。刚才也讲到对于问题排查机制的设计也非常重要。另外就是在链路跟踪，然后监控方面，如果日志设计得不够合理，后续这些工作都是难以去开展的。要怎么去实现前面说的这些需要去考虑的这种设计，一个就是细节是要统一的去约定这种错误码这需要非常的细节，因为错误码会最后写进运维手册，给到运维人员，他在操作间拿着一个运维手册，一旦你的业务出现一个告警，他拿着你的错误码就能对照手册知道你的业务大概出什么问题。如果你们有预案，它甚至可以不用打扰任何一个其他的人就能自己把问题解决掉。这样一方面是处理效率，一方面是处理的准确率都很重要。另外一块是说摘要日志一定要格式统一，并且明确。建议是使用拦截器打印对业务的介入是最小的。摘要日志后续会在监控中间会非常广泛的用到，在日志里面最重要的一个。另外其他的日志，也是推荐使用这种站位服务的，就是个括号，这种占位符的打印方式，因为其他的有一些知道的日志之前有一些同事会比较草率的就用 java ，在 java 下这些对性能是有一些损耗的，尤其是用量非常大的，这些都是一些细节。另外也要注意日志的异常处理，里面指的是说如果打印日志的代码出现一些异常。他是不能影响业务逻辑，一般情况下在打印日志这里一方面要用一些认为说比较规范的组件，另外一方面一定要有这种拆开的机制，或者说要把它能够在这种可控范围内，另外就是有一些敏感信息，一定要注意保密，或者是脱敏，尤其是像金融行业的一些客户，他会要去登录之类的账号的信息之类，这种一定要遵循这种监管的一个规定。要求敏感信息一定要有脱敏和加密的意识。
在 sofa 的整个的日志体系里，sofa boot 有一个比较完善的框架日志，让 sofa 应用一定要善于去用好它的发布的框架.比如说可以用 sofa Digest，用过的客户们都知道 SOFA是有 rpc 的 rpc server digest 表示说 rPC 的服务提供方，它的一个重要就是 rpc client Digest 表示说 rpc 的调用方，它的一个业务的摘要日志，用这个就可以统计出来他的一个调用的次数和调用的分部，所以说它的调用的状态，都是能够用日志做做一个统计分析。另外就是异常调用的排查，相信不管是用 SOFA 还是用其他的中间件，或者是一些其他的开发框架，包括 spring boot 都是日志的， arial日志它里面一定要干净,强调的是说用 arial日志更快速地去发现问题，然后去对这种异常的调用链做一些诊断，然后对好时做一些分析。也可以用发布的digest 的日志去诊断，说服务，它调用成功和失败的比率，因为是有一个字段叫做返回码，有一个明确的编码,正常反馈是 00，异常返回是其他。如果说返回的 04，会知道当前是找不到服务地址，这次调动调用方找不到它的服务提供者,这种含义非常明确的，返回码能够帮助去分析调用成功和失败的比率，以及大概系统发生什么问题。也会有，比如说 sofa 的 connection event 的日志，然后能够去判断服务的连接的情况，包括服务的提供者和服务的调用方之间的连接，以及他们和注册中心之间的连接情况,都可以通过 connection event 是去做一些判断，另外可以根据 digest 制作一些链路的跟踪分析，包括说复杂分析，复杂指的是比如 1 个服务部署 4 个副本，每一个机器上面已经承载多少的调用量，是不是负载是均衡的，也可以根据这些机器的 digest 摘要日志，然后来判断。另外就是这些调用一共耗时好多久，也是有字段来判断调用耗时。这叫做调用总耗时，也有可能说当前等待多长时间，业务真正处理多长时间，这些细节的耗时都可以在日志中间看到。一般情况下，基于 sofa boot 的业务应用，基本上能够通过发布的 sofa boot 做好业务的一个监控。
我们给客户做的一些监控的咨询方案，就是基于 sofa boot 的框架日志。因为部分客户，他不同的业务是以不同的项目组，这样的开发模式不同的项目组不一定能够制定出全行或向金融线的银行就是个所有的业务线，甚至整个企业级别的这种统一的规范不一定能制定出来。当然建议还是要能够制定出来一套就是统一的规范，如果制定不出来，比如说基于 sofa boot 的开发的，就用 sofa boot 框架日去做这件事情，已经完全足够。监控都要监控哪些东西，一方面是服务器状态监控服务器状态，监控上面指的是容器，容器里面的系统指标。 Gvm 的指标，GvM 系统指标指的比如 CPU，内存，磁盘 lo 的这些信息 GvM 的指标，包括这 JC foresee 这些情况，同理上面的容器是基于云服务器，还有底层的物理机，他们是环环相扣的，谁都不能出问题，所以物理机及云服务器的状态也是一样，要去监控的，监控的指标跟上面系统监控是一样的，它的 CPU 内存，然后 io 还有包括一些网络的情况到底是什么样子，都是要必须要去做监控，这是必备的。
另外 sofa 微服务的业务监控，只要你用 sofa boot 的框架，你不做修改，按照 demo 去执行开发，一定能打出来框架日志，基于框架是可以做一些业务统计和分析的监控异常以及关键字的监控，可以用它去感知到一些关键的节点，需要人为的去关注的问题，另外就是端口监控，这端口监控包括说比如说一个微服务的一个服务的提供方，他跟注册中心到底的连接是不是不正常的，比 sofa 中心是9600 端口，比如说微服务用到消息队列，跟消息队列的 brooker 的连接是不是正常的，要看 10911 的端口是不是正常的，包括微服务它是一个提供方,订阅方和提供方的之间的连接，是用以默认是 12002 端口，然后去建联一个长连接，长连接是不是正常的，当长连接正常才能进行这次调用。否则调用是找不到的，就是端口的监控。另外服务提供者的一个状态的监控，包括服务提供者是不是正常的。这是一个业务的监控，另外订阅者监控，跟服务提供者的监控是基本一样，他们都是 client，相当于两个都是业务应用，这两个业务应用要监控的东西也是基于业务，除服务器的监控以外，业务的监控就是看业务的需要。另外很重要的一点是要关注线程池。它在 sofa 也是有一个专门的日志，在个 boat 的目录下面，要去看线程池不是当前处于一个非常繁忙的状态，线程池是不是要满，明显是当下这台机器，业务处理不过来要立马去做的操作就是要扩容。或者对于某一些认为出现异常的一些业务链路，是不是要做一些降级，不要让它这种滚雪球的模式去把其他的业务都影响。另外消息队列相关的监控，刚才前面也提到一些，这里是在消息队列的发送方和消费方都要去关注的一些，就是说比如说消息的发送次数，是不是符合预期的跟业务量是不是能够匹配得上，另外消息发送的耗时是不是和一开始性能压缩的的个号是是能够对应得上是一个预期内的状态，消费的次数和消费的耗时是不是能够在预期内，以及当前消息队列堆积的状况是否正常，堆积时长非常重要，如果有短暂的堆积是合理的，但是堆积如果长时间不能被消费，是消费方有问题。消费失败的次数也非常关键，这是一个失败率的统计。以及说一些其他的关键字是业务上要根据自己的需要去做一些设计。任务调度的一个相关的监控主要是任务调度的触发的成功率，到底是不是能够按时地按照预期把任务出发成功。另外是出发成功之后是不是能够处理成功，处理的成功和失败的次数或者失败率也是非常需要去关注的一个点。大家可以根据自己选用的一些充电线的一些产品，以及说自己行业的一些现状以及监管的要求。然后去做这方面的一些监控。当然如果有相关的问题可以联系来做一些咨询。
监控和设计和监控都已经考虑好后，要做一个代码审查，就是 code review，code review 也是有一些方法，它不是说拉一个大会，然后把所有的资深的专家拉在一起，然后一个人在前面讲自己怎么样写代码，然后把整个系统的代码 review 完，这件事情就结束，这样子去做更多会变成一个任务性的，为 review 而 review，而不是说真的要去发现问题，对来说都会变成一个负担。在审查方面也是一个是需要做计划性的，要做分片的 review，不是整个所有代码全部写完之后再去做统一的目标，而是做完一个小的模块，甚至说 200 行代码，300 行代码，就要做一次 review，及早地发现问题，及早地从偏离的航道拉回来。第二代码审查本身是一个非常耗时，而且它是一个需要更多的去靠专家的经验去做的事情，还是希望他能够尽量地做一些自动化和工具化。之前阿里巴巴也输出一些包括叫做 java 的开发规范，也是有一些插件，支持 ide 的一些插件，知道包括开元一些方案送到 cube 之类的，有一些工具能够把一些认为是比较硬的指标，或者说一些能够用机器去自动化识别的指标，可以沉淀到系统里，然后让系统先帮做一次 review。然后人为地再去根据自己的经验检查，过程中没有机器，没有考虑到，或者说机器漏掉的问题，这样提高效率。另外有一点写代码就是不同的人，风格差异非常大，所以易读性一定不能忽略，不是说代码它能够完成业务任务就可以，而是这行代码它能够完成下去并且被其他人能够去维护。第二是要做一些测试的验证，包括压力测试，然后依赖的中间件的性能的评估，压力测试里面就是一方面是全链路的压测，另外一方面是对于中间件能够承受多少业务的量的评估，为什么每一次都说每次上限都要评估中间件的性能，因为在测试环境和生产环境有不一样，在生产环境一组中间件，比如消息队列，它是一组服务端，一组 brooker ，拿 sofa 来举例他承担非常非常多的业务。但是在测试环境不是这样，今天只有一个业务，甚至几个就个别几个业务在测试，broker 的压力就会很小，用测试环境在做压力测试的跟生长环境会有一点差别，这方面的差别也是要评估进去的，不但是说要知道每一个微服务他能够承受多少的业务量，也要考虑说当业务量增长上来的，到一个什么样的程度，中间件该扩容。另外有一些其他的高可用测试，一些极端情况有点类似于故障注入，但是这实是认为应该在测试阶段去做的一个验证，就是前面的设计到底是不是真的在这种极端情况下，甚至一些故障场景下，它能够生效。比如说一个旁路的业务，当业务量上来的，突然发现它的性能不行，是不是能够舍弃业务，用一个动态配置的方式把业务关掉，业务就绕过不太重要的业务链路，问题是到底是不是真的解决，在测试阶段要去试一试，如果真的到这种情况，能不能从服务管控制台把它关掉也是验证一部分。
另外一部分是投产准入，此时要做一些整体的发布计划以及需要对当前的这次发布的重要性做一些评估，需不需要去做专家的团队的护航，现在也会承担一些为金融客户保驾护航的这种服务的这种职能。有些客户觉得自己到一个非常关键的业务节点，他会要求比如说中间件专家组到客户的现场，或者是在远程的形式，然后去为他的业务 stand by。然后如果一旦出现什么问题，他可以随时找到，甚至在现场就能够及时的解决掉。现场客户或者说业务的投产的相关的部门，包括开发测试和运维。他需要做一些关键链路的一些验证方案，运营手册的检查，这些都是投产转入的一些检查这方面，包括 cr 的咨询，压力测试的咨询，以及压缩过后看到的一个结果不是很满意的情况下，是不是要做一些性能调优的咨询，这些都是有相应的服务。
最后会以一个常见的问题，以案列形式来介绍说明。当业务已经发布遇到问题，要怎么样去解决。在传统运维值班室有一个运维的老师，然后他能接告警，然后一旦出现告警，发现自己处理不了，然后就一下子就拉很多人，拉这么多人到底有哪些人能处理的，当他拉人时他是不知道的。所以在微服务的架构之下，尤其是引用到更多的中间件的情况下，会发现对运维人员的要求会更高。在有些行业他不是运维人员的职责，是一些架构的一些老师的职责来做这件事情，但是没关系，需要知道的是要运维好或者说是保障好一个生产环境的业务的稳定性，快速的做一些业务的排查，问题的排查或者故障的止血的，需要知道哪些东西，一方面是要知道详细的了解到业务架构设计是怎么样子的，它的关键路是怎么样，哪些哪些地方是最容易出问题的。另外一方面他对业务整个它依赖的一些组件的原理要有非常深入的了解，才能找到排查问题的思路，sofa 微服务经常出现微服务找不到服务地址，这种问题应该去怎么排查。问题的现象是微服务的情况下， rPC02306 的错误码，然后日志里面看到的 rpc02306 没有获得服务的调用地址，请检查服务是否已经推送。我们看到的 sofa 的返回码是 04，刚才也讲到 047 是找不到服地址的一个返回码。看到此问题时已经非常清晰它是服务的调用方连不到服务的提供者，问题需要从开发的角度和经验角度去分析可能性。
第一种是服务提供者他并没启动，只是订阅方或者服务调用方的开发，不知道服务提供者边是什么状况。他们要去看一下服务提供者，他启动没有他的 java 进程，如果服务提供者启动，但是没有注册成功，因为微服务有一个注册中心，在 HF 这边，叫做 config server，订阅方通过注册中心拿到服务提供者的地址，服务提供者也是通过注册中心去发布自己的服务，有服务提供者没有注册自己的服务到注册中心去。
第三种是服务提供者注册成功，但是服务本身有异常。他的 java 在但也发不成功，有可能服务提供者出现 Stop the word，他服务本身出现异常，还有一些抖动然后造成这种短暂的这种断联也是有可能的。第 4 种情况是说服务的订阅方没有成功的定阅，刚才讲到是有两个过程的，首先服务的提供者，他能把自己成功地发布到注册中心，服务订阅方，他要能从注册中心把自己需要的服务成功的订阅回来，有可能订阅方没有订阅成功。或者还有是一些其他的问题，就要结合现场的情况再做一些排查。但为什么能够怀疑到这些，并且能够排查下去，一定是基于右边的这幅图。
这幅图是 sofa rPC 的一个过程，这幅图是要求同学一定要熟记在自己的脑子里，一旦出现 sofar npc 的问题，这张图第一个时间冒出来，然后要知道它的过程。Service reference 和 service publish 都是业务的两个应用，他们都会 sofa 注册中心有一个连接。此时publish 他就会去注册中心发布注册自己的服务，reference 是从注册中心去订阅到服务的地址。并且它有一定的缓存的机制，它缓存在本地，真正去发起调用的是 reference 直接去直连 Publish ,如果直连成功调研就开始。一旦连接出现问题，就暂时找不到服务地址。这里面是怎么拿到注册中心的地址。蚂蚁的产品还有一个叫做 ac VIP,此产品就是发现中间的一些组件的地址，比如说注册中心的地址，比如说消息队列的地址是通过另外一个叫做 SVIP 的产品通过这张图可以发现现在的微服务的架构之下，运维它不仅仅是一个开缩机器，在上层微服务的运维或者稳定性保障的同时他一定要关注的是服务整体的架构是怎么样子的，中间依赖的一些组件里面的一些内部的原理是怎么样的，了解这些才能够更快速的脑子里形成一个排查的一个思路，或者排查的一个图，然后一点一点的去找一些信息日志，或者是一些监控的一些信息数据来佐证怀疑到底是不是正确的，这是对上层的服务的开发的更高要求。这部分也在 Java 排查问题和故障排查的过程也是积累一些经验。包括 sofa 微服务的整个中间的一些组件的架构原理，要看哪些日志，也包括一些常用的一些排查工具， t 萨的监控的工具怎么看,阿尔萨斯工具内存的工具怎么看， CYC 的一些信息怎么看，如果发现频繁的分 c 或者是 OM 的报错，是不是能看它的内存的 dump，怎么看这些可以做一些交流。
接下来就把前面聊到的这个从微服务开发到运维的这个全生命周期做一个简单的罗列。首先这个服务中间件的一些产品原理。然后由这个监控和日志的一些规范，代码审查要怎么做，然后微服务的这个压测和调优要怎么去做。投产的时候是不是需要去做一些护航的保障，以及说最后讲到说疑难问题，要去怎么排查，这些常用的工具不限于 sofa 应用，这些工具要怎么去使用一些赋能，这些服务都是目前也在做的，如果有需要，可以及时的联系。
以上就是这次的探秘为体系的一个就是精品课程之一的微服务全生命周期的稳定性实践一个内容。
