Serverless架构将会引领云计算的下一个十年，这是一个共识。互联网开发者一直有一个共识，如何才能研发提效，降低成本。
我们先来理解一下常规软件开发运维流程，当我们有一款产品在不断地持续跟进迭代开发时，需求的提出往往由运营或者产品经理对产品构思或者数据进行分析后提出，然后进行一系列多轮的需求评审、技术评审、测试评审。敲定后进行开发，然后测试，最后进行产品验收，最后才进行需求上线。
这样一套流程走下来，时间效率可想而知，不过往往会有方式方法来解决，例如：敏捷开发，这里我浅显的理解敏捷开发为把更多的时间花在“各种评审，需求确定”上来减少开发返工的时间成本来达到更好的软件开发，软件交付效率。
“大中台，小前台”相信大家不会陌生，通过中台形式将业务进行粒度划分，各自为政，需要时又能进行排列组合一般，通过数据上下游串联，来达到“一键开发需求、一键上线需求、快速响应需求变更”等效果。无疑，中台解决了效率问题。
Serverless也是我最近开始认真接触的一项我理解为是新的开发运维方式的这样一种开发方式？可以叫做新的开发方式吧，我觉得称为技术并不太妥当。
那么是如何演进到serverless架构的尼，我们先看看以前的单体架构，我们进行软件前后台开发后，我们的后台，数据库都跑在一台具有公网能力的服务上，或者现在的ECS，这样做是有什么问题尼？
1.服务器出现故障怎么办，应用瞬间宕机
2.单台物理机无法承受巨大的流量，即使你代码写的再好，多进程写的多棒，最后一定会受到单体机器的限制
解决办法就是我们可以加一个负载均衡，将多台单体进行均衡分配，流量分配，便可解决以上问题。
但是尼，作为开发者你可以想一想，企业级项目绝对不会是一两个人就能够完全cover项目的，一定是多人多团队共同参与，那么利用以上多单体负载均衡实现的方案，由于单体互不独立，在进行merge时候一定会有大量的冲突，会有大量不可快速解决的麻烦事，研发效率可想而知会直线下降
为此就有了微服务架构，将我们的单体拆分为可以单独开发。单独测试，单独部署的应用，相互之间通过http、rpc等进行通信，是否就解决了上面所提顾虑？。
推荐一本书《Nodejs微服务》还可以
但又可想而知，微服务带来的就是分布式新挑战，以前只用运维一个，现在要运维十个，当然现在成熟的框架方案，成熟的结构架构方案都可以解决以上问题，本文这里只是给出架构演进中优缺点。
来到云原生架构，依托云服务，原来都是自己研发分布式服务，或者基于别人的基础之上研发，云原生架构，业务可以直接使用云服务，能使得我们不再为分布式头大，头大的事交给别人，其实，有时候也会思考，不断地对效率进行优化，会不会带来的就是开发者们的低能发展，这点我觉得是需要开发者们时刻注意的，保持不断学习是很重要的。
网上有个理解我觉得挺符合自己的思考的：在架构的演进过程中，研发运维人员逐渐把关注点从机器上移走，希望更多地由平台系 统管理机器，而不是由人去管理，这就是一个对 Serverless 的朴素理解。
serverless, 架构 — Feb 26, 2021
Made with ❤ and at Earth.