【摘要】 华为云的Go语言编程底座是如何炼成的？

Gopher China作为国内最权威和最实力干货的Go大会，致力于为广大的Gopher提供一线分享交流机会，也为众多一线互联网公司大咖深入探讨Go语言的应用发展提供契机。

在近日于上海召开的第六届Gopher China大会上，华为云微服务首席架构师田晓亮就受邀分享了《华为云的Go语言云原生实战经验》，讲述如何构建韧性、高可靠、安全的云原生应用系统，并孵化云原生应用开发框架Go chassis，以提升团队开发效能。

自华为在2016年成立Cloud BU以来，就引入了Go语言编写的kubernetes，Prometheus等CNCF项目，华为云的研发团队也开始用Go语言来构建云服务。不过，当时Go的生态并不完善，所以要自己从头到尾编写基础能力模块。

那么，如何用Go构建云服务并将基础能力慢慢建立起来，且听我们慢慢道来。

一、从一个简单云应用看我们如何构筑一个云服务

和Eureka一样，一个简单的注册发现服务Service Center可以通过多种手段来增强。

1、静态与动态信息定义

减少数据信息量，抽出公共部分统一管理，通过静态信息来划分实例组。这样微服务与微服务实例为1对n的映射，将微服务名、版本、数据中心等信息都抽到了公共部分，通过降低冗余度，来减少网络的开销，同时也规范化了微服务模型。

2、契约化微服务

上一张图我们看到微服务静态信息里面包含了多个Schemas，里面关联了微服务所关联的契约文档，同样是1对n的映射关系。通过手动上传或者代码自动生成文档上传，可以在注册中心中查看微服务文档，且文档与微服务版本绑定，不允许更改。

对比客户端开发团队等待后端的服务编写完成后，才开始进行集成开发的方式。高效方式是以文档为基准，客户端与服务端同时开发，客户端通过Mock去除对服务端的依赖。

为何要保证文档先行？如果文档不及时审视，那么将会出现非常糟糕的情况。比如不一致的命名规范，定义相似的API，扩展能力差，任何一点都会大大增加研发成本。及早审视并规避十分重要，这就是为何注册中心加入文档上传与查询能力。

3、服务间依赖管理

调用层级过高将引起定位困难、性能下降的问题，合理的层级是3个服务：a->b->c的调用就可以完成一次调用。彼此互相依赖的两个服务在功能升级或者变更时要花费更多时间来分析影响，比如ab互相依赖，一个新功能涉及2个都要更改，那怎么一起上线？

简单的依赖有助于系统测试和分析，这给架构师一个很好的审视方式，可以及时看到微服务间的依赖关系，以及时对架构调整。

4、缓存机制

由于Service Center内部本身是不存数据的，一旦etcd出现网络故障的时候，就会导致Service Center不可用。所以Service Center引入了异步缓存机制，启动之初，Service Center会与etcd建立一个长连接，也就是watch。为了防止建立watch时间窗发生变化，又做了一层保护，在watch之前做全量的查询。运行过程中查询所得到的资源变化会缓存到Service Center本地，然后进行异步的循环。

总的来说，我们通过了多种手段来提升微服务研发效率，减少网络开销，并通过异步缓存提升性能。这是华为云积累的能力，但交付一个云服务远远不止交付业务功能这么简单，还要考虑微服务的安全、韧性、隐私、可运维等能力。

我们刚才看到的只是水面之上的冰山，水面之下还隐藏着大量的基础能力需要编写。真的要达成微服务架构模式的愿景，需要繁重的工作量。就像冰山那样，我们要将通用能力沉淀下去，能够复用。如果让各个业务团队同时照顾冰山上下，各自开发各自的，那结果将是灾难性的，企业用人成本极高，下面让我们展开Service Center的架构看看。

二、立足Service Center架构，“冰山下”的基础能力库编写很重要

下面这个组件主要负责微服务的注册发现，提供Restful API。

它有四个主要的模块：

• 服务注册发现：通过注册发现完成服务拓扑的感知；
• 契约发现：每个服务具备一个契约记录，支持多种格式如Open API，gRPC proto；
• RBAC：基于角色的访问控制，管理员可以管理账号，将账号分发给微服务或者不同人员；
• 服务治理：针对微服务下发治理规则，比如重试，限流，熔断，路由策略等。

交付一个云服务远远不止交付业务功能，而是要去全方面的考虑安全，韧性，隐私，可运维等能力，当然我们将部分的能力可以交给一些中间件来完成，比如网关。然而仍有大量功能需要自己编写，且可以复用在每个微服务中，这就是基础能力库编写的初衷。

• 配额管理：云资源按照租户进行配额管理，租户所能使用的资源受到严格限制
• 告警：当微服务发生关键问题时要直接上报告警系统，而非通过云服务设置阈值等告警策略
• 安全：加解密证书，密码
• ID生成：ID的生成算法，用于生成微服务ID，实例ID等
• 多种中间件：调用过程需要被审计，调用链追踪，生成指标监控等

该项目已经开源并捐献给Apache，项目地址https://github.com/apache/servicecomb-service-center

对于这些能力，抽取普通的库函数也是完全不够用的，所以要做到如下能力：

可插拔：也就是按需在编译期引入（受限于Go语言能力），例如配额系统的具体实现在社区是不需要的。

异构系统：也就是一个功能要有多种具体实现，比如审计，公有云存在一套审计系统需要对接，而社区则是本地日志打印。

不同的算法：解密工具、ID生成器……面对不同的交付场景或安全要求，都要通过不同实现来替换算法。比如ID生成可以是snowflake、UUID；加解密算法使用AES或者其他公开算法。

三、如何通过Go Chassis加速云服务开发？

为了满足上面提到的需求多样性，并且让所有新规划的组件受益、快速进行开发，我们需要统一的框架和标准来加速开发，这就是华为云用Go语言编写的开发框架Go Chassis诞生的原因。所以大家看可以看到go chassis的源码和设计有着service center代码的影子，感兴趣的同学可以去深入阅读下。

从Go Chassis的开发框架可以看到，业务逻辑是用户自己编写的业务代码，框架分为协议层、中间层和插件套件三部分，管理部分是云服务，框架开发出来的应用可以快速对接使用这些云能力。比如：

• 注册发现插件可以对接Service Center与kubenetes
• 配额管理插件可以对接云服务的配额管理服务
• 中间件如指标监控对接到prometheus

那么如何通过这个框架来加速我们的开发呢？

手段1：将后端服务作为插件使用

后端服务指的是不由自己组织开发并运维，从应用运行到基础设施不可见的黑盒子服务。常见的后端包括配额管理、认证鉴权服务和对象存储服务，云原生的其中一个要素是把后端服务当作附加资源。

当我们调用这些后端服务时，其实它们并不在微服务的治理体系内，考虑到可测试性（比如mock测试）以及可替换性（业务能够连续，且随时更换更好的服务，应对变换的需求等），我们需要将它们插件化，以灵活的进行选择替换或者去除。

手段2：沉淀需求基线

在我们提供任何一种服务前，我们都需要满足基本的要求，比如：

• 请求体必须做大小限制
• API必须限流
• 密码不能明文存储
• 访问进行认证鉴权
• 无单点故障
• 访问审计
• 运维能力

考虑到这些需求，首先要将运行时的调用模型标准化。由于不同部门会有私有协议诉求，那么服务治理就交给核心框架完成，协议由业务部门决定自主研发或是集成现有协议。

当公司内部不同部门都在开发自己的协议做自己的服务治理时，再将业务统一在一个架构、工具链上，就非常困难。

所以，我们使用Invocation概念来统一协议描述，这样就可以在统一的处理链中进行处理。

处理链的设计满足AOP，也就是在业务处理的前后加入代码逻辑进行特殊处理，比如审计用户操作。

ResponseCallBack 用于接受后置handler返回的结果，所以每一个handler处理时都可以按需定义自己的ResponseCallBack来获取后面handler，甚至是业务逻辑代码的执行结果，让通用逻辑（即中间件）和业务逻辑彻底解耦。

目前Go Chassis已经支持的中间件包括限流、熔断、负载均衡、认证鉴权和审计，都用此机制来实现：将公司全部的工具链，服务治理手段，安全合规等都落入到处理链中，来快速加快研发速度，并统一规范，减少管理负担。

框架内部提供给了命令式调用能力，比如指标收集。

也提供了声明式使用方式，比如流量管理，其具备基于流量特征的限流能力。

从插件能力全景图可以看到，Go Chassis目前已经支持多种生态，并对多种后端系统提供了抽象接口，从而帮助应用快速开发。

通过这样的框架，我们可以让业务团队专注于业务代码开发，而无需理解后端的复杂性和其他非功能需求。带来的收益如下：

• 对于庞大的系统可以进行mock测试，提升交付质量
• 应对不同的交付场景
• 保证后端可替换性
• 研发职责界面分离

从架构或者业务演进的角度来思考，后端使用的技术是在快速演进的，我们需要通过后端服务的快速替换来确保系统和产品的及时演进，所以接口设计的可替换性大于可重用性。这也满足程序设计原则的依赖倒置，当我们再开发一个新的微服务时，仅仅需要实现他的业务逻辑即可。

手段3：通过配置简化开发流程

这也是一种命令式调用方式，其结构如下：

Source层: 配置源是一种标准接口，可以通过实现一个source来接入不同配置源，它定义配置来自哪个资源：可以来自远端系统，来自本地文件，来自环境变量或是启动命令行。source负责将配置项缓存到本地内存，用户可以选择加载任意的source实现。

remote source：对接分布式配置管理系统，目前对接了携程开源的配置中心Apollo。

Config manager：负责整合管理所有source的配置，每个source可以定义优先级，当通过manager获取配置时，如果2个不同的source有相同的配置，那么就会取最大优先级的配置。

Event Dispatcher：用户可以通过Archaius API进行配置变化监听，当source内部的配置项新增、更新、删除、时，都会通知监听器。

Source优先级：优先级由大到小依次为Config center、CLI、ENV、file，当有相同配置项的时候仅优先级大的配置生效。在一个分布式系统中，远程的配置中心理应拥有最大优先级。而在本地运行一个独立的进程时，通常的思维是命令行参数优先级高于环境变量，高于本地文件内容。拥有了这样一套机制后，用户就无需再写代码处理配置项生效逻辑。

Archaius API： 封装底层实现，提供友好的API供开发者使用。

其中，内存source非常重要，它使得UT测试更加简单。File source使得本地进程的测试可行。远程的配置中心比如携程的Apollo，则帮助系统进行联调测试并支撑生产环境。

手段4：易处理

意思是它们可以瞬间开启或停止。 这里我们不会谈到快速的开始，因为Go语言和Docker运行时，容器平台就能处理这样的一个场景，所以我们谈谈面向意外的处理。

这个Protocol server通常代表一个协议，也可以是某种编程模型，比如http。

还有个框架的配置样例，意思是在一个微服务进程中拉起了2个http端口和grpc端口服务。

在收到系统信号后，就会遍历的停止每个server。

另外由社区开发者贡献的自定义优雅停机功能，可以允许用户劫持信号和停机处理过程，也可以在前后自定义处理过程。

手段5：轻量级内核

目前，Go Chassis只依赖必要的prometheus、opentracing、jwt、k8s client、Go-restful相关的依赖库。

注册发现也是可插拔的。

另外，包括grpc协议、kubernetes注册中心等多种能力都在另一个仓库中提供，可以按需引入

四、拥有自己重新制造的轮子

拥有自己重新制造的轮子是Go Chassis开发框架logo想要传达的理念。

我认为真正有能力的团队不会自己重新制造轮子，因为他们懂什么是轮子，什么样的轮子适合自己，并将这种抽象的轮子引入并进行增强，打造成更加适合自己的轮子，你是“越野轮子”还是“雪地轮子”，品类皆由你定。我们将自己研发团队积累的能力抽象成多种接口及插件，为的就是不要重复制造轮子，而是基于现有轮子重新打造，让项目产品跑的更快。

五、Go Chassis的案例分享

首先是基于Go Chassis和Service Center进行服务治理的视频通话后台，其一直应用于华为荣耀手机和智慧屏等终端上，且上线了公有云，有效支撑终端公司畅联通话上亿注册用户。

第二个案例是基于Go Chassis开发服务治理底座的边缘处理能力，它管理全国29个省、自治区的将近10万边缘节点，超过50万边缘应用的部署。支撑了1万多个收费站的门架信息采集业务的不断调整、更新，满足了每日3亿条以上的信息采集。为日后车路协同、自动驾驶等创新业务的发展提供了良好的平台支撑。

（https://github.com/kubeedge/kubeedge）

除此之外，华为云ServiceStage就是无缝托管基于GoChassis开发的微服务，并在此之上提供免运维的微服务引擎功能

（ https://www.huaweicloud.com/product/servicestage.html）

六、总结

1、定义你的应用开发通信协议

一家公司非常重要的两样东西是企业文化与行为规范，这是每个公司的领导者必须优先定义的事情，它就像是一种通信协议，保证团队之间能够良好的协作。这样领导者就无需事必躬亲，甚至可以做到无为而治。这套机制就是所谓的“通信协议”

所以定义一套通信协议是非常重要的。Go chassis就是Go研发团队的通信协议。

每个微服务都是个小团队开发的，有可能是同一个团队，也可能是不同团队，我们所做的框架是为了定义一套最简化的范式（接口与模型），以此来减轻研发的成本，同时兼顾扩展性，不要对开发有过度的限制。我们规范化了API first来审视API设计，依赖管理来审视合理的服务关系，并规定所有的能力要沉淀为插件与中间件，而这些都是为了定义研发团队开发与治理云服务的“通信协议”。

2、Go在新基建中的作用

互联网演进第一代是PC，第二代是手机，第三代便是万物互联，5G时代允许更多的设备接入，而较小的设备势必会催生新的半导体，新的操作系统（比如说华为鸿蒙），这样一层层下去，势必会需要一种新的语言及对应的框架，Go语言的特性就很契合这样一个位置，而分布式的设备也需要一种框架来进行治理，Go Chassis也将在这里扮演比较重要的角色。

综上，我认为Go语言很可能成为基础设施领域的一个开发底座，从kubeedge、视频云等项目使用Go Chassis就可以看出端倪。