对ServerLess架构的调研

上一周的调研中发现的一个业务演化趋势是从单点重服务向多点的微服务演进，通过扩缩提供更可控和更强大的服务能力。分布式提供的服务能力几乎是无上限的，但是也带来了运维上的压力。为了解决运维的难题，出现了k8s这样的集群驾驭软件。将服务打进容器中后让k8s承担很多运维工作，比如扩容、更新等等。

k8s是一个很好的解决方案，但不是全部。k8s存在其短板：
1、依然无法解决对硬件进行监控的问题。k8s可以检查服务的健康状态，对于服务依赖的物理集群却没有办法提供监控。虽然已经将软硬件的监控任务分开了，但是随着集群的扩大，硬件层面的健康监控压力会变得很大。
2、开发人员依然不能全心集中于业务的开发，为了使用k8s还需要再学习k8s的使用，增加了前期的学习成本和技术栈长度。

k8s的框架下，业务应该尽可能地是无状态和单元化的。为了解决上面的两个问题，比较好的一种策略是让云服务商来提供解决方案。而在一些云服务商那里，还有一种解决方案也很值得关注：Faas。

Faas在阿里云的实现是函数计算，在腾讯云是SCF，在AWS是Lambda。Faas相比于k8s做的更加极致，这种形态下，业务被抽象成了函数。开发者甚至不需要关心容器化，只需要关心自己的业务怎么提炼成输入-输出的模式。对于开发人员来说运维基本为0（除非自己搭建私有的Faas平台，运维从业务中剥离的一个结果就是运维会越来越专业化，也会越来越复杂）。结合对象存储等，serverless可以为中小公司节省掉很多成本。
Faas并不是完美的，为了达到开发的专一，需要作出一些牺牲，可以预见到的是：
1、要想办法将有状态的服务变为无状态的解决方案，比如session式的会话要考虑变成jwt去鉴权
2、可能需要额外的组件对必须有状态的业务进行支持，比如websocket，腾讯云提供的解决方案是API网关，即将状态保持做到了业务前一层
3、开发的自由度上需要作出一些牺牲，为了适应选择的Faas平台，很可能会在开发上受到限制，甚至是语言选择上的限制（SCF不支持C++）。
4、服务间调用需要依赖云平台的支持。原先的开发下，我们的服务是单点形态的，不同的业务单元相互调用是内部可以解决的问题。如果使用Faas，我们把业务单元化拆开，那么业务单元之间的调用很可能需要云平台提供内部API调用支持。而这又增加了一些限制。