From Cloud Native to Serverless
Published:
1. 从云原生说起
在了解 Serverless 之前，张金柱老师先带大家回顾了什么是云原生（Cloud Native）。简单来说，Cloud Native 是“一系列架构、研发流程、团队文化的最佳实践组合。”
也就是说，CloudNative 不是某一种技术或最佳架构方式，而是一种集合，一般情况下，它与云有强相关，包括公有云、私有云，包括京东、BAT 内部也有一些云的架构，云的基础设施，在此基础上搭建一整套研发流程和团队的工作方式。
主要技术点
弹性，过去单体软件架构或私有机房时，流行托管或采购物理机，资源有限，随着业务流量增加，扩展性很差。在有云的情况下，利用其规模、基础设施更容易做到弹性扩容和缩容;
多租户；
自服务，大家可以像购买商品一样去通过 API 便捷地去购买云上的资源；
基于API协作，如今云上也集成了 AI 等各种基于 API 方式提供的服务，大家可以更便捷地去使用；
分布式；
反脆弱性，互联网系统最担心宕机，而通过云的能力，我们可以引入高可用的架构、进行破坏性测试等；==和可靠性的区别==
按需申请和计费，云把 IT 的基础设施商品化，让大家能够根据自己的需求去实时申请和释放。
通过下图可以清楚了解到，在架构上云原生上是如何去落地的。云提供敏捷开发基础设施与公共服务，配合微服务达到可扩展性高、可用性高、性能强、一致性的云原生架构。
云原生可以理解为多个阶段的进化过程：
第一级：单体软件架构，一套系统解决了所有的问题，但这时它的优缺点都非常明显，虽然架构简单了，但同时也牵一发则动全身，如只想修改一点东西就导致整个服务停掉。
第二级：是由微服务的架构带来的升级。主要是让大家做到关注点分离、减少团队沟通、提高效率。
第三级：云结合微服务框架带来的改变。根据Gartner最新报告，以后会有云资源管理运维的职位，主要将各家的云的资源和服务通过 API整合起来，提供给上层的业务开发者。
第四级：就是今天的重点，Serverless的几个主要特色有
- 免运维、甚至结合 AI 能力做运维的提升；Oracle对于数据库自动配置优化、SQL优化。 - 弹性伸缩； - 按需付费； - 高度自动化和自愈能力等；
2. What is Serverless
2.1. 对Serverless的定义与理解
UCBerkley 曾对Serverless做过一个研究，主要强调了 Serverless 不是FaaS。各家公有云上都会有一些函数服务的产品，但这只是一个Serverless在计算层面上的抽象和实现，Serverless还有大量的服务，如==AWS 的 S3==、==京东的对象存储、KV存储==等。Serverless 给大家带来的是便捷的申请，按需付费。
云从某种程度来说，是将大家的技术集中，由专人负责，并且将数据打通形成平台。如今云概念的发展相当于真正地给 Serverless 插上了飞翔的翅膀，主要因为Serverless脱胎于云时代架构的思想，Serverless是只属于云时代的。云的基础设施层（IaaS），它可以为Serverless的弹性提供基础，让「弹性」有了真正落地的可能。
不仅如此，回顾云计算的历程，从早期的虚拟化（网络、计算、存储）、到 PaaS、SaaS，到如今Serverless的出现，这是云计算进入深水期的体现。对于应用开发者而言，开发模式是否有变更、效率是否有提高、成本是否有降低、这些需求是一直以来都存在的，而Serverless是符合这个阶段的，它直面了这一些问题。
特别强调的一点是，Serverless不等于FaaS，它提供的是弹性的计算服务，FaaS只是一种计算资源的抽象方式。
2.2. Serverless的常见落地场景
Serverless的常见应用场景，可以分为以下几类：
后端应用
随着 App 移动开发的兴起，大量 Server 端和移动端已经做了很好的解耦，后端本质上是一个 Web 服务，包括 IoT 的后端。比如智能家电，每时每刻都在产生数据，并将数据上传到云端。所以对于海量物联网设备产生的海量数据，只有具备弹性能力的系统才能满足其需求。
事件驱动的场景
这类场景包括文件处理、流数据处理、ETL 等。它产生的事件是可以跟函数服务绑定的，完全可以由队列服务配合去实现。在Serverless的场景下，只要有一个事件，就可以去驱动任务的调起。
AI 应用类
举个真实的案例，有一家做智能客服的公司，虽然夜里咨询量不高，但也会配备一些运维同事值班，因为智能客服一旦出现问题，就需要有运维的干预。而使用Serverless架构就可以把运维的事情完全托给云厂商，完全不用担心夜里扩容或故障报警。
值得注意的是，BaaS和PaaS需要区别开。BaaS主要是以API的方式给用户提供服务，并且这些服务是一个用户架构里面通用的功能；而PaaS概念很广，包括数据库、中间件、Web Server等,都可以囊括进来。因此，可以简单的理解为BaaS是PaaS的子集。
3. Serverless应用场景
目前，Serverless还是一个蓝海领域，相关标准还没有统一。但各大厂商都在积极推动相关的规范和运营标准的统一化制定。
Serverless的常见三层架构：客户端、服务端、数据。所有的事情都可以在这里去处理，包括购买、搜索、用户管理等。
下图展示了电商场景下，Serverless的架构图：
最后再说一说常见的Serverless的工具，主要包括公有云、私有云，以及对Serverless平台的包装工具。开发者可以基于Kubernetes搭建Serverless架构。
4. Serverless的未来
说了那么多Serverless的优点，其实Serverless的未来，还是有不少挑战的。主要包括以下几个方面。
- 首先它忽略了时效性。过去的 Web服务可能是一个后端，用户请求处理完了就可以返回；但在Serverless架构下，用户请求的路径变长，导致服务响应时间变慢，==Debug成本更高。（飞机）==
- 它阻碍了分布式系统的开发。在Serverless中，有一些事情，如选举、数据一致性、事务等，无法很好地解决。导致一些必须通过分布式架构来解决的需求，无法实现。
- ==用户思想上没有完全接受（接受不了，永远是个备选项）==。这一点主要体现在对安全的担忧，将自己的数据全都交出去，还是不能完全放心。==没有公认成熟开发框架或方法论（需要通用的底层，同时也会是话语权之争，靠近国家者胜）==，==做不到完全不关心底层。（分出专门的领域，没人关心如何加工一个螺丝）==
- IaaS层的挑战，在Serverless下，我们希望容器能做到启动速度越来越快，性能损耗越来越小，这对IaaS层提出了更高的挑战。
虽然挑战多多，但随着云基础设施的日臻成熟，Serverless也将应该更好的发展。总结起来一句话：未来，已来！
- FaaS作为后端使用，避免资源浪费。
- 小程序的兴起，Serverless落地的好场景，只用服务，无后端。
- Sam，AWS对于Serverless的管理平台
- 90%都处于被触发状态的Serverless服务，是否还有价值做Serverles？
- 按平台购买，按配置量购买
- 云函数是否可以取代微服务
- 云结合微服务构建系统，微服务是组织服务范式，底层的架构还是用云，二者是不冲突的
- 做应用后端的场景和微服务框架做整合
- FaaS在哪些场景不适用
- FaaS是无状态的，才能做弹性扩容，但是对于有状态的服务，则不太适合
- 服务常驻，触发率过高，以及Function执行时间过长的服务