转载

从去中心化到扁平化管理(11.15)

注：图片来源 https://blog.csdn.net/define_us/article/details/84812729

在谈微服务架构设计的时候我们已经谈到过，传统的一个单体应用被拆分为了多个微服务模块，而这些微服务模块之间本身也通过API服务接口进行交互。如果这些模块需要对外暴露接口和提供能力，往往就需要通过API网关进行服务注册接入，并提供统一的对外能力提供，这种情况下API网关本身可以实现服务治理和管控。

但是如果不对外提供能力，我们前面谈到过微服务模块之间的API接口交互往往是通过服务注册中心进行，但是服务注册中心本身服务治理和管控能力相当弱，很多类似日志审计，安全，流控等能力都无法达到。而这个时候就涉及任何需要API网关来进行服务治理管控。

API网关本身是中心化的，那有没有一种完全去中心化的架构？

这也就是前面我们谈到过的ServiceMesh服务网格和SideCar，简单来说就是服务网关的关键技术能力全部下沉到微服务模块中，和微服务模块一起部署。Service Mesh 直译过来是服务网格，目的是解决系统架构微服务化后的服务间通信和治理问题。服务网格由 sidecar 节点组成。

Sidecar 在软件系统架构中特指边车模式。这个模式的灵感来源于我们生活中的边三轮：即在两轮摩托车的旁边添加一个边车的方式扩展现有的服务和功能。这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦：原来两轮摩托车的驾驶者集中注意力跑赛道，边车上的领航员专注周围信息和地图，专注导航。具体到微服务架构中，即给每一个微服务实例（也可以是每个宿主机host）同步部署一个 sidecar proxy。

在采用这种架构下，我们来看如何实现统一的日志监控和管理。

如果我们将服务运行实例日志全部存储在微服务模块App Server本身的应用服务器上面，那么显然是很难对这些日志进行统一管理，存储和结构化处理的。因此最佳的方式仍然是我很早就提到过的，sidecar代理在获取到日志信息后仍然需要将该信息异步推送到消息中间件，再由消息中间件写入到统一的日志存储中心进行统一的管理和监控。

即实际的服务运行管理过程本身是完全去中心化的，但是对于后续的监控管理仍然是有一个完整的元数据配置中心和实例日志的存储管理中心，以实现统一的管理和监控。

联想到我们常说的扁平化管理也是同样的道理。以一个项目团队来举例说明，很多管理和协同往往都需要团队成员将问题和需求上升到项目经理，再有项目经理跟进实际情况将任务分配到不同的岗位角色人员处理，最终再进行反馈。这种模式虽然是增加了沟通环节和次数，但是一个关键的好处就是资源信息本身是可以复用的，同时可以减少大量不必要的重复沟通和协同。

如果是完全去中心化，可能存在A向B要一个文档，但是C同样在向D要一个文档，在这种情况下单点沟通随时快捷了，但是出现了大量的重复无效沟通，资源本身也没有得到有效的复用。

如何解决这个问题？

我觉得完全可以借鉴去中心化的技术架构里面的思路，即沟通过程本身是点对点的，但是沟通过程和交互输出本身却需要进行集中化归档，同时给归档库提供一个全文检索功能。再好一点就是人工对归档库进行结构化归档处理。这样在新的需求出现的时候，我们应该是首先对归档库进行搜索，在没有发现可复用的资源后，再进一步寻求协助，而协助本身也会是一个广播的方式进行发送，并寻求响应。

基于这个思路，你会发现当前的类似QQ沟通群本身就是一个好的基础载体，唯一要改进的就是沟通信息本身如何更好的集中化归档和结构化处理，形成强大的资源搜索库。这将很好的解决在传统去中心化沟通模式下，需要群体中每个独立个体之间都能够做到完全相互了解和默契配合的要求。

原文 http://blog.sina.com.cn/s/blog_493a84550102z4m7.html

正文到此结束