用Goldilocks原则探索微服务治理平台

用Goldilocks原则探索微服务治理平台

“金发姑娘原则(Goldilocks principle)”源自童话《金发姑娘和三只熊》的故事 *:

迷路的金发姑娘未经允许就进入了熊的房子,她尝了三只碗里的粥,试了三把椅子,又在三张床上躺了躺,最后决定小碗里的粥最可口,小椅子坐着最舒服,小床上躺着最惬意,因为那是最适合她的,不大不小刚刚好｡

在去年的一篇博客《 微网关与服务啮合 》中，我回顾了云原生生态下微服务的部署架构历经组件、代理、网关，一步步发展到现在的边车微网关(Sidecar MicroGateway)和服务啮合(Service Mesh)模式。

今年，在开展微服务治理平台落地的过程中，对这个方向有了更深的理解和实践，由于k8s等 工具 带来了运维效率的大大提升，我们看到越来越多的企业IT部门开始采用容器化平台。

然而这些平台在带来便利的同时，并没有带来与传统数据中心完全一致的安全级别。

中台服务在公有云平台上发布API，引入了更复杂的网络环境(4层和7层协议更多样的组合)与集成问题(公有云与企业数据中心的安全互通)，因此也需要更新的工具和方法来解决这些新的问题。

我们正在构建的微网关管理平台 (MicroGateway as a Service，下面简称MGWaaS)，是一个以微网关部署为核心功能的平台服务，是微服务治理平台的一个核心组件，企业可以使用这个平台，规划各个区域集团的IT基础设施，同时用归一化的标准进行微服务的统筹，并且快速地帮助微服务团队搭建起具备数据面(Data Plane)与控制面(Control Plane)能力的微网关实例，减少各团队之间的工作量重复与实践混乱度。

迷路的金发姑娘走进了MGWaaS

在设计MGWaaS的过程中，我们假设了几种可能的集成方式，并且希望从中选出一个作为MGWaaS的最终部署架构。然而，在大型跨国企业中，项目情况复杂多变，实际上很难存在一种完全一致的部署结构，因此我们几乎是在尝试着各种部署结构的过程中在寻求该服务的Best Practice，就像迷路的金发姑娘走进了熊屋，需要通过各种可能性的方案逐渐推导出最合适的方式。

完全点对点的集成策略

在最初的阶段，我们设计了相对去中心化的集成结构。

这种方式集成的MGWaaS实际上只是作为一个部署工具存在，真正提供给微网关使用的基础设施，可能存在于任何一个网络空间，我们只将几个集群划分为资源池（k8s集群），MGWaaS作为工具可以帮助这些资源池完成微网关实例的整备，并交付给微服务团队使用。

在这种设计下，由于大部分的安全能力如“认证授权”已经前移至微网关中实现，微服务与微网关之间的网络互通与安全策略就成了困难。我们遇到的一个难题，就是如何确保“可弹性扩容的微网关实例”(非固定ip)与“机密的微服务实例”(外部访问来源需要严格控制)绑定，设计这样的一个逻辑网络空间，需要依赖复杂的VPN专线来支撑，这无疑增加了网络维护的混乱度和工作量。针对这个问题，随后我们讨论了两种其他的实施方案。

基于PaaS平台的集成策略

相对简单的方案是PaaS管理所有节点，在平台内划分MGWaaS的资源集，并利用平台提供的SDN(如calico、flannel、vxlan等)组网能力，划分集群内的租户。确保微网关实例与微服务实例的网络互访，并设置安全的防火墙策略。

这种实施方案依赖PaaS平台提供的基础设施，并需要额外的平台SDN层定制，由于网络环境的复杂度较高，调试往往非常困难，因此也对IT基础设施的网络开发运维人员能力提出了更高的要求。毫无疑问，并非所有运维团队都具备定制如此复杂平台的能力，因此我们也期待未来会出现这一问题的成熟解决方案。

优势与困难并存的Sidecar策略

在文首提到的 博客 中，我们重点提到了Sidecar模式，之所以会提到Sidecar是因为在“Service Mesh”的概念下，Sidecar被作为一种具备实操性的部署方案提出来，并逐渐成为一种经典实践，恰恰是由云环境的复杂性决定的。

在使用Sidecar时，参考Istio的实现方式，我们需要在服务Pod创建时，通过k8s的webhook功能，为容器注入sidecar proxy进程，并读取微网关与微服务相关的具体配置，由于proxy与service位处在同一个Pod中，微网关可以便捷地使用localhost指向容器内的服务，将组网的复杂度从微服务的开发团队中隔离出来，并且能减少不恰当的组网带来的安全风险（因为每个携带Sidecar proxy的Pod都会携带必要的认证功能）。

在性能方面，由于Sidecar Proxy存在的位置相较于PaaS方案离微服务更近（甚至直接寄生在同一个容器内），因此网络延迟带来的影响变得更低。

尽管Sidecar模式具有相对优秀的性能和简单组网的优势，但随之而来的挑战是额外的k8s注入器开发工作量。并且每个受管控容器都需要注入sidecar，由于1：1的进程配额，也带来更多的资源开销，要实现灵活的配置也考验网关平台的设计能力。

金发姑娘做了决定

为了方便比较，我们可以将不同类型的方案的优势与困难都记录在下面的表格里：

经过一轮分析，以及对现有运维平台与工具逐渐深入的了解，我们目前MVP阶段仍然选用P2P的部署方案，在未来的演进中，利用好未来PaaS平台提供的SDN或Mesh功能，通过组网自动化力图减少运维的工作量，减少开销的同时，提高灵活度、性能和安全性，势必会是这个平台持续的主题。

Goldilocks 是一个很简单易懂的童话，我在STRIKE team实现ed448-Goldilocks的时候第一次接触到了这个“金发姑娘”，当时很诧异，为什么要给一个大质数起一个如此可爱的名字，仿佛是在告诉论文的读者，作者经历过非常周密的考虑与试验才确定了最后的设计，多么通俗的大道理呀。然而生活往往是“听过很多道理，却依然过不好这一生”……

我们在设计架构的过程中，会遇到各种复杂的场景，并需要在先进又激进的新理念，与陈旧却稳妥的旧方法中做出选择。而使用更量化的方式，有助于我们平衡各种优势与困难，找到支撑最终选型决策的理由，并规划出清晰的发展路线，这就是金发姑娘的智慧，找到最适合自己的床，才能睡得更香。