概要

此文章基于贝壳-赵亮在”2021年5月29日Ocon软件大会第二天-多语言异构场景下的一站式服务治理方案和实践”的演讲后做的个人总结。

一、目录结构

背景问题

解决问题-微服务框架Keboot

服务治理-稳定性APM:监控、报警、日志、链路、诊断

服务治理-流量治理:摘流、重启、限流熔断、验签鉴权

服务治理-基础设施:框架、配置、注册、网关、调度、API、服务集市

服务治理-容器:应用上云、云上架构

二、题外话

基于此次软件大会，可以发现一个很突出的特点，优秀的技术人员会把细节把控的很棒，并且很实用，及时总结，及时反思，及时落地，从不拖拉，严于利己，心胸阔达，热爱分享(一定要学好知识，为什么呢？一是自己要学好，二是要传播知识，传播文化，自己学好了才能不误人子弟。)。

三、演讲逻辑

首先说业务，然后说现阶段模式，接着说出现的问题/痛点与改进方式，达到一种什么效果，再接着说出现的问题/痛点(前面的流程线:循环渐进的说)，最后做总结。

细致入微，把某个点说透，让别人知道架构怎么演进，而不是只是让别人觉得自己公司的架构很牛，而不能实现落地。

在这次大会中各个演讲者的差距很明显(不仅仅是技术)，真正脚踏实地做技术的大牛仅占比20%左右。

微服务框架

做技术架构的三个要素:

时代背景

技术现状

现状具备的能力

无论是SDK、agent、mesh，都是不变的服务治理的能力，只是手段在演进，目的都一样。

怎样，开箱即用、方便。

统一一个微服务框架，规范SDK等情况，掌握了框架就能了解用的那些插件。

现阶段这些背景的现状导致质量不高、人力浪费、故障频发。

20%的故障大多是因为插件的选择不当导致的。

面向配置的编程。

基于配置化，定制starter实现分布式服务，里面连接了一些云厂商的中间件，开箱即用。

这个是体系化，可插拔。

让业务线只关注自己的增删查改和架构，不用关系任何基础设施的任何东西。

衍生出来的敏捷开发的思想:

申请资源(配置，如DB信息)流程打通，配置中心下发，和申请的环境资源打通，可以使代码在新创建应用的时候，中间件连接在代码里就能启动起来，资源ready，代码CI到各个环境，甚至说，如果测试人员同意的话，那么可以把代码直接CD到线上。

资源、代码和环境三个维度:

检测每个代码使用的应用框架的组件版本，在CI的阶段给予报警，在生产上可以查询中每个java组件的所有版本。

PHP框架:高性能、高内聚。

统一迁移版本。

涉及营销的概念，做技术架构，两份靠技术建设，八分靠推广和落地。

选择的一个最大的业务方合作去做这件事，既作为客户，也作为建设者，帮他去推广整个PHP的规范。这是个落地的经验。

入口处。

在创建项目的时候，都要创建git仓库，选择所有必须的组件，都植入到git仓库中，其实在申请仓库的时候就是一个应用，拿到这个应用就可以完全部署下来。

一部分是架构贡献，一部分是业务开发贡献，有联系方式，做到最后要把服务治理做成公司内部的生态，谁都可以贡献组件，架构来把控质量和标准，让大家都用起来。

公共问题:压键盘、拖库。

压键盘，TOB的场景，把键盘扣在地上，不同的重复提交，导致数据库连接池被打满。

拖库:select没有limit

这俩问题通过公共组件解决。

这些公共组件出现的问题，是有质保和售后的。

在同一个应用发布一台线上的灰度，引流压测，完全相同的背景，新的微服务框架，性能又20%的提高。

其实做中间件，做的优化体验，对于端对端，用户的感觉来说，其实从网络侧、用户侧、服务侧，其实很多事情可以做。

升级是一个很大的痛点，新的应用没问题。老的花了80%的时间，怎样升级的KEBOOT框架。

每个组件都会碰到一二十个坑，很多的列表，而且springboot1.X、MVC升级到springboot2.X问题handler不住。

强制其他组升级，不升，帮他升

推动所有业务组统一升级，痛点。

有些20%业务线比较积极，50%摇摆，20%顽固。量化出来。

服务治理 -稳定性

这里加了报警和诊断。

报警是所有监控的入口，只有有事了才看，报警非常好，监控带来的曝光度/效果才非常有效。

止损:回滚、摘流、重启、一键降级

出现问题，不会立马分析，20%的问题是找不到的，直接扩容了，所以加了报警和诊断。

一些人刚开始就把指标配置全，什么时候做监控，从监控里要看到什么内容。

三个场景:

专门固定团队盯着，看到所有应用里出现的问题在哪里。很多页面是没数据的，只有出问题的时候，要把相应的数据展现出来，给故障组能够看到。

业务巡检:每天早晨看报表。

故障定位:上下游，故障指标，横着的才是在出现问题的时候突出的某个点可以做关联分析，帮其认识到可能是由于下游的某个慢SQL导致的。这个case。

出现问题并不是一个个去找，而是报警能链路到想看到的内容。报警内容对其有帮助。

报警的OKR指标，哪些有用，对哪些业务线的止损时间减少，比如2分钟左移，就是报警的内容。

报警，比如，关联的应用，有没有做过变更的指标。

页面做的程度，可以让一个没有任何经验的工程师快速止损。

贝壳是skywalking的深度使用者。

搭建很容易，但各种语言，各种场景使用是挺难的。

接口出入参，安全统计。

自定义关闭采集组件，每次升级版本，基于agent机制而不是SDK机制，导致兼容性不好，推广力度快，出现问题，立即降级，采集不起作用，采集agent能定位到应用级别。

以业务维度看链路情况，比如业务ID，一边看到的是接口链路，一边看到的是业务链路，可以完全知道整个装修流程的问题环节，这在整个产品、运营都能看得多。

这个agent已经打到容器了，只要替换容器就行了。

要知道具体中间的地址、场景，这个是动态的，做了静态的标注也不一定全面。

衡量接口的三大指标:耗时、请求数、错误数

这个服务使用的哪些资源，比如中间件地址。

最大的跳转:GO / PHP ，全、准、及时。应用达到90%的效果才看的比较全，20%就没那么全。

日志直接ELK的包装，没花费太大的精力。

热搜索

采集端的配置

容器环境下比较麻烦，采用flunbeat解日志的方案，在容器中能实现TOPIC，直接打到TOPIC，这样以前接到日志的做的监控报警在上到容器环境的时候，不用做任何更改。在上云做基础设施时有深入的感受。

用的阿里的arthas

不要让研发人员登录到任何生产机器做任何事情。

所有诊断分析都是通过页面直接解决的。

流量治理 -快恢止损

多组件:其实就根据heathcheck去做。

用sentinel。

多的功能是，通过IP地址和USER来做针对性的某一个配置规则的去限流。

代码无侵入，可看到所有代码的情况，可配置接口的限流策略，可不是去接入这个限流。

可看到所见所得的限流，可看到限流之后减少的情况。Prometheus采集的数据操作所见所得。

把apollo做的配置规则做下发。

把prometheus采集数据做所见所得。

贡献了sentinel一些代码。

推广服务框架，上容器的时候，最大的一个点就是QU回归的工作量，动一个框架或中间件，QU怎样回归，基于sandbox字节码增强的方式实现了下述三个功能2-4。

在测试环境，容器用的比较多。

资源浪费很严重。

右边的图，虽然一个基础服务，调用这个大家都用的基础服务，但是能告诉底层这个下游服务，在调它的下游的时候是所期望的服务C，这块比较难，这样就可以灵活的配置，可使用ketrace和zk配置中心来实现这个原理，使用之后，使用率降低了许多，这是架构线和业务线一起合作的，从业务中来，到业务中去。

验签鉴权是有单点风险的，怎么避免，一定要做本地化。

秘钥的方式一定要做到本地化的方案。

本地化的验签鉴权怎么把这个到页面，

密文存取和KMS做合作，密文存文件，出来也做加解密，防止数据在DB中是明文?密文?的展现,实现一个点，配置哪些字段，哪些字段就会密文存到本地，读的时候也是密文读出来，就是面向配置编程，只需要十行的配置就能实现这个能力，这是框架提供的场景。

基础设施

这个apollo实现共享内存，各种语言下本地调用的方式，这里的agent演化成mesh的方式，每个语言的调用问题，每个语言的apollo的SDK升级都是一个痛点，在目前没有MESH的情况的一个过渡方案。

把eureka和ZK慢慢迁移到NACOS。

Eureka在客户端拉取全量和同步的时候，应用量很多的时候会带来很多的问题。

这在上容器的阶段，注册中心一旦放到线上，会立马引流，其实要在线上环境做一次压测，这个迁到nacos，双注册中心场景不谋而合。

注册中心只是一个基础能力。

分为大网关和小网关。

大网关是最上层的所有SLB层，各种BFD、FE。

小网关，springcloud-gateway，性能不OK，但业务场景满足的非常多，后期要在ingress层把小网关的能力加上。

借鉴了各大云厂商的接口。

左边是所有的应用列表，隐私，注释掉了。

这些接口并不是数据接入就能看见的，通过ketrace，通过trace链路，域名的监控，只要上线了，应用和接口都能看到。

右边是所有应用在打包的时候，接入业务方的时候，能走线上化的流程，被接入方能自动生成代码，可做一些接口级别的限流和熔断、鉴权都做进去，因为要抓到业务方经常联调的场景。作为提供方，也可以设置哪些接口需要做鉴权，别人去接入的时候，都要走鉴权的流程，还有申请流程，特别是基础服务需要。

基础能力接入的在线化，其实是和服务框架集成的。

服务治理 -容器

正在做的事，通过微服务框架，能把应用的改造和上云的成本减少，这是微服务框架带来的益处。

比如JDK1.9版本，导致上云的亲和度不够。

设置标准版本，框架和平台打通所有版本，那对于业务线来说只需要升级一个版本即可。

用户无感，适配已有的场景。

所有的agent打包成镜像放上去，业务方只要升级一个版本即可。

在容器环境上，服务治理该怎么做？

绿色的，是容器化必备的能力。

技术架构能做的一些点:扩充策略、围绕监控指标怎么去根据上下指标声明式的做扩缩容，而不是定义它扩多少、缩多少，多种的发布能力。

容器环境最大的问题，就是环境治理，环境的不一致、环境的使用成本、环境的浪费，通过上文可以解决的。

使用mesh解决异构的链路。

一系列流程。

可以看到微服务框架隔离业务线对K8S这一套基础设施的理解。

上容器的三个维度。这里属于中层。

下层有IAAS层，运维层。上层有整个云平台的产品介绍层。

依赖于下层的K8S能力、存储能力、网络能力，来建设服务治理整个体系。

上层就是对整个服务治理体系的产研的流程做了一些改变。