有点难，需细品（上）(微服华为能力服务底座)

那么，如何用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的架构看看。

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

它有四个主要的模块：

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

该项目已经开源并捐献给Apache。

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

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

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

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

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

更多干货，敬请期待下一期揭秘。

点击“了解更多”，了解基于GoChassis开发的微服务