简介|微服务是一把双刃剑，在提高开发效率的同时，也使得操作和维护变得更加困难，尤其是微服务器粒度更小的Serverless。随着数量的增加，缺乏配套设施的架构将变得难以管理，治理和运维难度也将成倍增加。本次分享主要讨论如何对无服务器进行更有效的服务治理。本文整理自MegaEase和腾讯云TVP创始人陈皓在Techo TVP开发者峰会“无服务器的服务治理”2021中国区的演讲。
点击观看精彩的演讲视频
1.什么是无服务器？
如今的“无服务器服务治理”突然让无服务器变得更重了，但有时候可以放到生产线上的企业级东西也是如此。我们需要明白，简单的东西背后并不简单，就像我们家里打开水龙头或者插上插座，都是有电的，但背后供应自来水和电的那套东西却极其复杂。
为了说明这种复杂性，让我们从无服务器的历史开始。它于2006年在伦敦的一家公司Zimiki成立。当时的口号是“边走边付”，听起来好听，但在商业上却极其不成功。你可能没有听说过这家公司，因为它是在2017年关闭的。然后在2008年，谷歌的App Engine出来了，仅限于Python，包括超时60秒的HTTP功能、Blob存储区和自带超时的数据存储区，但最终被谷歌云平台取代。还有PiCloud平台，旨在通过三个操作简化云计算，但也失败了，2013年被Dropbox收购，Docker的前身dotCloud也以失败告终，但在Docker作为开源开放后火了起来。国内APP Engine，如TAE、SAE，当时都在做，但都因为运营惨淡而失败。
2014年，伴随着AWS Lambda的功能服务计算模型，2015年加入了API Gateway，使得Serverless卷土重来，与现有云服务合作大放异彩。谷歌拿出欧米茄系统的思路，开辟了Kubernetes，不仅解决了环境部署的问题，还解决了一整套调度、编排、架构的问题，在今天相当流行。在Kubernetes的加持下，2016年是谷歌云功能、IBM云功能、Azure功能……2017年是Cloudflare CDN，其次是Knative、OpenFaaS、Kubeless、Fn。Open lambda、ironbonds、fishing、Apache open晶须等开源软件让Serverless再次走红。
那个无服务器已经相当于FaaS了吗？其实这是有原因的。
首先，我们的基础设施越来越完善。就像我们今天的编程一样，程序员不关心如何分配内存，如何制作TCP网络包，只关心RPC协议。他们大多基本不关心资源是怎么消耗的。这说明我们的硬件资源、操作系统和编程语言都做了大量的资源管理和调度工作。当这些配套设施越来越强大，我们就可以进入“资源独立”的视角。这也称为无服务器。
另外，我们必然会有各种各样的定制需求。例如，我想向文件存储服务S3注入一些业务逻辑，这仍然非常常见。让我给你举个例子来理解——Oracle数据库的存储过程和触发器。有时候，我们不只是想把数据存储在数据库上，而是希望它能有一点业务逻辑。因此，数据库的存储过程和触发器是为用户的定制需求而生的，想要入侵标准化的基础设施。同样，业务逻辑必然会入侵你的云设施和云服务；为了应对这种情况，使用函数/插件的形式是合乎逻辑的。这种情况与今天的FaaS非常相似。
这个场景很合理，技术的时机也没问题，因为我们的基础设施越来越好，不再关心系统管理、服务器运行、代码部署、监控日志等。我们只关心如何尽快将代码转化为服务。
第三个维度是业务逻辑。基础设施和技术手段永远无法降低业务逻辑的复杂性。业务逻辑的复杂性不能靠技术降低，只能通过优化业务来降低。也就是说，您不应该认为通过微服务/无服务器/FaaS可以降低业务复杂性，这是不可能的。试想，一个轻的函数怎么能把重的业务逻辑放进去呢？如果只是简单的事情，那也没关系，但是这个世界总是想在简单之后变得复杂，需求总是一点一点加起来，总会有复杂的事情。一旦这个事情复杂了，我们该怎么办？想象一下，在生产环境中，如果我们都玩微服务或无服务器，今天的实例数量可能会增加1-2个数量级，从10个增加到10.1万个。如何管理？
下面，让我们来看看Serverless面临的一些技术问题。
二、无服务器相关问题
我们有没有想过这些问题:无服务器如何发现服务？如何进行健康检查？灰度发布或者A/B测试怎么做？有没有想过需要监控哪些指标？我们今天做的是生死检查，那么如何监测健康检查呢？除此之外，无服务器还有两种，一种是以工作流的方式安排，另一种是以消息的方式进行事件驱动，甚至一个小的无服务器直接调整RPC库中的另一个。如何做通话链追踪？或者业务流程跟踪，如何管理它们之间的依赖关系？容错处理呢？如何保证SLA？基础设施的服务水平永远不等于业务的服务水平...当这些问题来临时，就很麻烦。我想说的是，如果我们想成为一个“Hello World”和一个玩具，很简单，想做什么就做什么；然而，如果你想制造一条可以扩展和工业化的生产线，那将是非常复杂的。
我们再看一遍。这是2019年AWS校长SDE在国外无服务器论坛上的PPT。他用“无服务器已死”作为他演讲的标题。Serverless并没有死，但他想用这个东西吸引大家:不在乎Serverless这个名字，只在乎Serverless能做什么。无服务器本质上是做什么的？这里有几点。首先，无服务器可以降低操作和维护的难度；其次是性价比高。它密切关注成本和使用情况。它希望以非常低的成本给你更好的体验。它不需要购买服务。其成本将比直接购买服务器的成本低1-2个数量级；然后开发人员可以做任何事情，他们可以成为操作和维护人员，SRE，这就是DevOps的本质——把Dev变成Ops。剩下的就是，例如，它可以处理许多用户案例、安全性、最佳实践等。，而你不需要在意这些。
接下来我就来说说技术的发展，这是我个人总结出来的。以前云计算基本上是基于资源的运维，也就是我把资源和软件当资源卖。如今，云计算已经成为一种应用服务，这也是Cloud Native诞生的原因。为什么谷歌在图片前面？他们是极其高水平的球员。先说一下背景:在移动互联网时代，谷歌几乎被摧毁，但它制造了安卓系统。如果不开源安卓操作系统，想象一下今天会有哪些公司占领手机操作系统。肯定是苹果和微软，长期在操作系统上下功夫，也有移动设备的操作系统。谷歌落后，必须开放安卓系统作为开源，并配合大量玩家打第一第二名，所以非常成功。这个套路还在继续，K8s也是开源的，但谷歌绝不是开源公司。两三百个产品死了以后就不开源了。它的开源是为了先堵后得自己的市场。
另一种云是由谷歌提出的，但谷歌云并不成功，甚至不如微软，因此它通过Kubernetes建立了云原生基金会CNCF。CNCF的项目基本都是开源的，和之前的安卓套路一模一样。他的目的是改变游戏规则，因为如果走资源型的道路，他肯定玩不了，所以游戏规则从资源型变成了服务型和应用型，他会在开源生态中做，然后竞争。如果K8s被用作资源级别的缓冲区，那么哪个云供应商没有任何意义。所有云厂商甚至都可以自己搭建私有云，谷歌的cloud自然继承了K8s。
而且我真的相信趋势一定是从资源型转向服务型，所以今天我跟很多公司运维的同学说，你们CMDB还是资源型，已经落后了，所以一定是服务型，应该照顾的是服务而不是资源。
澄清这个道理，我想说服务器不是没有Service。没有服务器，应用程序开发人员就不会关心基础设施。基础设施有很多东西:配置管理、维护和操作，只关心如何尽快将代码转化为服务。要做好这一点，我认为有三个核心:
1.应用服务是一等公民，资源不再；
2.外部API是重中之重；
3.整体SLA是重中之重；
它意味着服务、API和SLA，一切都要围绕这三个来做。如果每件事都做得好，那么无服务器自然可以实现。即使是无服务器也没关系，因为我们主要关心的是服务，而不是资源。这是否意味着我们可以提高开发效率，更快地开发和上线？有没有可能有更高的性能和更好的稳定性、可扩展性和安全性？运营维护成本降低了吗？你管理好成本和使用了吗？开发者能更自然地融入DevOps/SRE吗？我们知道一个运维经常会涉及到开发者，那么这个无服务器的支持设施能不能更好的让开发者无缝的做这个运维而不被别人催？
3.无服务器系统需要哪些配套设施？
个人认为无服务器最基本的配套设施包括底层资源的扩展和整理，以及整个栈的可观测性和服务治理。服务治理很重，SOA需要这些，但今天仍然有几个需求:服务注册发现、健康检查、配置、容错，最后是流量；如果没有管理好流量，在外部API中很难做到。我们一个一个来说:
首先是可观察性。我遇到很多公司作为监控系统，出来的时候我说:“我们监控了5000个指标，这不算什么。我们有10万个指标。”我觉得这些东西都是没有意义的，数据也是没有意义的，所以关联数据是有意义的。数据不是只和数据相关，只有在数据相关之后，才有信息，只有在信息中找到因果关系，我们才能称之为知识。科学就是一轮又一轮地做成千上万个科学实验，收集数据，然后找出数据之间的相关性，并把它联系起来，找到因果关系。一旦找到因果关系，就可以推导出一个公式，这个公式就是知识，这个公式是可以复制的。我们所有的数学物理都是这样来的，所以一定要把它联系起来，然后才能找到因果关系。那么我们如何联系呢？我们希望看到这样一个关联图，从直接服务客户的前端API到后面的Service，Service使用的是哪个中间件，这些中间件运行在哪些资源上？如果不能把这条链上的所有数据都链接在一起，我觉得无服务器是做不到的，运维难度很大。假设我只关心某个功能，但是它运行在哪个服务器上，它的调用链是什么，后台或者中间件的其他云服务是什么？如果这些东西都没有准备好，你会觉得这个东西只是一个玩具。
此外，还必须解决应急和体检、快速故障定位和SLA报告、容量分析等问题，因为一定有很多波动和很多数据需要关联。做卫生系统并不复杂，但是关联数据是很多公司不做的事情。为什么不做呢？因为很多公司的组织架构是分的，组织架构中肯定有一群人是基础运维，另一群人是应用运维，一群是后端开发，还有前端手机开发，各做各的健康体系；也使用云服务，云服务有自己的监控。组织结构是分的，不是一个整体设计，但Serverless强调的是整体向下设计。
再看交通管理，包括交通保护。你可能听说过节点着色，但你从未听说过流量着色。非常有用。流量着色是一种灰度发布。例如，当用户发送请求时，我会在门户API中标记他。假设这是我的灰度用户，我总能沿着业务调度的流量框架给出整个呼叫链的新版本。流量必须是彩色的，否则很难做灰度发布或者蓝绿部署，A/B测试更难。还有流量过滤，是一种安全还是一种保护。你有太多的无服务器和函数，有时你需要安排它们。你需要调整ABCD做一个，可以聚合也可以排列，这是流量网关需要做的。然后降级满足自我保护；还有容错管理，包括对后端负载的一些融合，这是流量管理的特点。让我们再来看看服务治理。
服务注册发现，启动无服务器服务后如何注册和被发现？如何支持多版本灰度？是K8s的DNS服务注册发现，还是应该使用传统经典的java技术栈服务发现？然后是配置管理。正如CMDB刚才所说，我们必须从服务的角度，而不是资源的角度来看。CMDB非常重要，但必须从服务或API的角度来看。还有健康检查。我该怎么办？今天很多公司说健康检查是一个比较低级的做法，看流程是不是上不去，叫生死检查，只有停机和上两种状态。什么是健康？健康是半死不活，亚健康，要求有的OK，有的不OK，有的更快，有的更慢，这才是现实生活中的事。K8s的活跃度和就绪探测器在实际应用中是有问题的，因为它们会重启，可以合理地说，服务有时在不健康时无法重启。还必须考虑应用程序的可观察性、吞吐量、响应时间和错误率。
第四，整体解决方案
一般来说，我们有两种方法，一种是Mesh，另一种是SDK。SDK有些侵入性，但是因为有些静态语言只能嵌入，为什么一定要嵌入呢？因为我必须知道应用程序内部发生了什么，以及内部的一些响应时间。另一种Mesh模式，现有的Mesh模式，比如Istio，是跨语言的，但是它有很多小问题，可观测性不完全，尤其是不能嵌入到应用中。JavaAgent是一个非侵入性的观察应用程序。如果是Java部门非常好的手段，作为非侵入性手段很容易实现。监控和服务管理，包括流量管理，都在sidecar和Java Agent中完成，而Sidecar在外面，Java Agent在里面，流量和服务管理交给Sidecar。两个都没问题。我觉得有K8s会更好，Mesh。
由于时间有限，我就不谈Istio中的问题，只谈方法论。我们希望如下图所示:
左边是传统的东西，很简单，怎么一下子变成这种样子？好像很复杂，但是如果左边服务数量是一百个，你会觉得这边东西很合理，就不会觉得是过度设计。我想说的是，左边是Spring Cloud一个小的宠物医院的演示应用，我们有一个像这种Mesh Ingress的管住流量，它会把这些流量转到sidecar上，通过应用上的JavaAgent保证灰色流量可以被跟踪，这样就可以进行整个调用链内的灰度转发。另外，我们的控制台服务治理，会帮你自动注册，Service可以完全不关心这些，我们配套设施全部以这种方式来建设，就可以真正做到比较完美的 Serverless。但是今天的Serverless Mesh做得非常有问题，它要把这一套服务治理扔掉改成另外一套，你就会觉得有点别扭。我们正在做一套完全兼容现有Java体系的 Serverless 的方式。
