本文首发于“雨夜随笔”公众号，欢迎关注。
在 云原生中的网关 中我们介绍Ambassador模式如何来代理服务和更改服务与外部的联系。今天我们来学习一下云原生中的标准化设计。我们知道云原生最大的特点的是复用，所以会出现很多很多可以使用的组件。但是当我们需要对这些组件统一管理的时候，问题就出现了。我们发现我们需要去修改每一个组件，但是组件的语言和设计都一样，全部修改显然是一件非常困难的事情。
但是这个问题不是只在云原生才能遇到的，回顾软件设计模式中，就有针对过这种问题提出过一种设计模式，那就是适配器模式--adapter。而云原生中理所应当的站在了这座巨人的肩膀。在很多地方都可以使用到适配器模式。比如我们现在已经部署了很多微服务，现在为了维护，需要增加一个针对全平台的监控系统，包含具体的链路日志，以及对每个服务进行资源监控，更重要的是我们需要对每个服务的健康情况进行实时监控。而这些面临的问题是我们无法找到一个统一的方法或者工具来解决我们的问题。
那么如果是你，该怎么办？我们很容易想到修改每个服务的逻辑来实现这些业务，但是很多时候并不简单，比如日志这一块，如果我们原来的日志组件不支持现在的日志管理接口或者更改代价过大的话，那么修改起来可能需要很多工作。同时我们需要在现有的各个服务之间做平衡。有些服务可能是第三方组件，并不能直接修改，有些可能涉及的修改范围过大，所以我们这样做的代价实际上随着组件的复杂度和数量可能会变成指数型上升。
但是这个设计是个很好的触发点，在 云原生如何来进行HTTPS升级 中我们介绍了Sidecar模式，可以在不修改员服务的情况下为服务增加额外的功能。在这里我们可以使用这个来设计我们的监控系统，如下图：
这样设计的好处在于：
- 我们不需要修改原来的业务逻辑，也就是和原来的业务逻辑解耦。我们可以选用我们擅长的语言和框架来设计具体的适配器。
- 我们可以根据需要来讲服务进行划分，比如将控制台日志转成我们的日志格式。这样可以大量减少我们的工作，并且我们设计的组件可以进行复用。
- 得益于目前云原生的蓬勃发展，已经有很多成熟的适配器，我们可以直接进行使用，而大大减少我们的工作量。
适配器模式
在云原生的架构设计中，适配器模式是很重要的一种模式。因为云原生中有很多组件，所以很多时候当我们需要设计一种适用于全部组件的通用组件的时候，很自然的需要适配器模式。而且云原生生态中很多都在往这方面努力。
云原生的适配器模式的概念是：当我们设计通用组件的时候，比如日志，监控或者健康检查等，我们需要考虑现存的接口，只有兼容越来越多的适配器，这个通用组件才是成熟的。比如目前非常流行的监控和告警系统Prometheus。
Prometheus
Prometheus是目前云原生中非常流行的日志和监控系统，在很多成熟的业务系统中都有使用。其架构设计主要是通过从不同的exporter中拉取具体的指标（自己定义的格式）来实现具体资源的监控。所以这里的exporter就是我们上面所说的适配器。我们来看一下Prometheus的架构设计图：
而在Prometheus的官方仓库中我们搜索exporter可以发现，官方定义的适配器就有15个：
其中有针对主机的node_exporter，针对mysql的mysqld_exporter等等，这些exporter负责将原来服务或者机器的指标转成Prometheus能够解析的指标格式。更不用提社区中许多非官方的exporter。正是这些工作使得Prometheus逐渐成为成熟的监控的告警系统。
总结
云原生中的不断发展，诞生了很多的功能强大的组件，我们也不断将服务进行拆分成不同的服务。可以说云原生的发展使得我们的开发变得自由了许多。但是随着自由度的增加，带来的是通用组件开发的难度，我们在设计通用组件的时候，相比于考虑修改原有代码，不如把相应的适配工作单独出来做成适配组件来增加其复用性。
