用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,就像迷路的金发姑娘走进了熊屋,需要通过各种可能性的方案逐渐推导出最合适的方式。

完全点对点P2P的集成策略

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

1.png

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

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

基于PaaS平台的集成策略

2.png

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

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

优势与困难并存的Sidecar策略

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

sidecar.png

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

3.png

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

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

金发姑娘做了决定

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

4.png

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

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

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