74 lines
9.9 KiB
Markdown
74 lines
9.9 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
06 _ 无服务时代：“不分布式”云端系统的起点
|
||
你好，我是周志明。今天是探索“演进中的架构”的最后一讲，我们来聊聊最近一两年才开始兴起的“无服务架构”。
|
||
|
||
我们都知道，分布式架构出现的最初目的，是要解决单台机器的性能成为整个软件系统的瓶颈的问题。后来随着技术的演进，容错能力、技术异构、职责划分等其他因素，也都成了分布式架构要考虑的问题。但不可否认的是，获得更好的性能，仍然在架构设计中占有非常大的比重。
|
||
|
||
在前面几讲我们也说，分布式架构也会引入一些新问题（比如服务的安全、容错，分布式事务的一致性），因此对软件开发这件事儿来说，不去做分布式无疑是最简单的。如果单台服务器的性能可以是无限的，那架构演进的结果，肯定会跟今天不一样。不管是分布式和容器化，还是微服务，恐怕都未必会出现了，最起码不会是今天的模样。
|
||
|
||
当然了，绝对意义上的无限性能肯定是不存在的，但相对意义上的无限性能其实已经实现了，云计算的成功落地就可以说明这一点。对基于云计算的软件系统来说，无论用户有多少、逻辑如何复杂，AWS、阿里云等云服务提供商都能在算力上满足系统对性能的需求，只要你能为这种无限的性能支付得起对应的代价。
|
||
|
||
在工业界，2012年，iron.io公司率先提出了“无服务”（Serverless，应该翻译为“无服务器”才合适，但现在用“无服务”已形成习惯了）的概念；2014年开始，AWS发布了命名为Lambda的商业化无服务应用，并在后续的几年里逐步得到了开发者的认可，发展成目前世界上最大的无服务的运行平台；到了2019年，中国的阿里云、腾讯云等厂商，也发布了无服务的产品。“无服务”成了近期技术圈里的“新网红”之一。
|
||
|
||
我们再看看学术界对无服务的态度。在2009年云计算刚提出的时候，UC Berkeley大学就发表了一篇论文“Above the Clouds: A Berkeley View of Cloud Computing”，文中预言的云计算的价值、演进和普及，在过去的十年（2009~2019年）里一一得到了验证。十年之后的2019年，UC Berkeley的第二篇命名风格相同的论文“Cloud Programming Simplified: A Berkeley View on Serverless Computing”，再次预言“无服务将会成为日后云计算的主流方式”。
|
||
|
||
由此可见，主流学术界也同样认可无服务是未来的一个发展方向。
|
||
|
||
虽然工业界和学术界在“无服务”这件事儿上都取得了些成果，但是到今天“无服务”也还没有一个特别权威的定义。不过这也不是什么问题，毕竟它没有我们前面讲到的微服务、SOA等各种架构那么复杂，它最大的卖点就是简单，只涉及了后端设施（Backend）和函数（Function）两块内容。
|
||
|
||
|
||
后端设施是指数据库、消息队列、日志、存储等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件。这些后端设施都运行在云中，也就是无服务中的“后端即服务”（Backend as a Service，BaaS）。
|
||
函数指的就是业务逻辑代码。这里函数的概念与粒度，都已经和程序编码角度的函数非常接近了，区别就在于，无服务中的函数运行在云端，不必考虑算力问题和容量规划（从技术角度可以不考虑，但从计费的角度来看，你还是要掂量一下自己的钱包够不够用），也就是无服务中的“函数即服务”（Function as a Service，FaaS）。
|
||
|
||
|
||
无服务的愿景是让开发者只需要纯粹地关注业务：一是，不用考虑技术组件，因为后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；二是，不需要考虑如何部署，因为部署过程完全是托管到云端的，由云端自动完成；三是，不需要考虑算力，因为有整个数据中心的支撑，算力可以认为是无限的；四是，也不需要操心运维，维护系统持续地平稳运行是云服务商的责任，而不再是开发者的责任。
|
||
|
||
你看，这是不是就像从汇编语言发展到高级语言后，开发者不用再去关注寄存器、信号、中断等与机器底层相关的细节？没错儿，UC Berkeley的论文“Cloud Programming Simplified: A Berkeley View on Serverless Computing”中，就是这样描述无服务给生产力带来的极大解放的。
|
||
|
||
不过，无服务架构的远期前景也许很美好，但我自己对无服务中短期内的发展，并没有那么乐观。为什么这么说呢？
|
||
|
||
与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、 无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式。除非是有重大变革，否则它也很难具备普适性。
|
||
|
||
一方面，对一些适合的应用来说，使用无服务架构确实能够降低开发和运维环节的成本，比如不需要交互的离线大规模计算，又比如多数Web资讯类网站、小程序、公共API服务、移动应用服务端等，都跟无服务架构擅长的短链接、无状态、适合事件驱动的交互形式很契合。
|
||
|
||
但另一方面，对于那些信息管理系统、网络游戏等应用来说，又或者说对所有具有业务逻辑复杂、依赖服务端状态、响应速度要求较高、需要长连接等特征的应用来说，无服务架构至少在目前来看并不是最合适的。
|
||
|
||
这是因为，无服务天生“无限算力”的假设，就决定了它必须要按使用量（函数运算的时间和内存）来计费，以控制消耗算力的规模，所以函数不会一直以活动状态常驻服务器，只有请求到了才会开始运行。这导致了函数不便于依赖服务端状态，也导致了函数会有冷启动时间，响应的性能不可能会太好（目前，无服务的云函数冷启动过程大概是在百毫秒级别，对于Java这类启动性能差的应用，甚至能到秒级）。
|
||
|
||
但无论如何，云计算毕竟是大势所趋，今天信息系统建设的概念和观念，在较长尺度的“明天”都是会转变成适应云端的。我并不怀疑Serverless+API的这种设计方式，随着云计算的持续发展，将会成为一种主流的软件架构形式，无服务到时候也应该会有更广阔的应用空间。
|
||
|
||
如果说微服务架构是分布式系统这条路当前所能做到的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。
|
||
|
||
虽然在顺序上，我把“无服务”安排到了“微服务”和“云原生”时代之后，但它们并没有继承替代关系。我之所以要强调这一点，是为了避免你可能会从两者的名称和安排顺序的角度，产生“无服务比微服务更加先进”的错误想法。我相信，软件开发的未来，不会只存在某一种“最先进的”架构风格，而是会有多种具有针对性的架构风格并存。这才是软件产业更有生命力的形态。
|
||
|
||
我同样也相信，软件开发的未来，多种架构风格将会融合互补，“分布式”与“不分布式”的边界将会逐渐模糊，两条路线将会在云端的数据中心交汇。
|
||
|
||
今天，我们已经能初步看见一些使用无服务的云函数去实现微服务架构的苗头了，所以把无服务作为技术层面的架构，把微服务视为应用层面的架构，这样的组合使用也是完全合理可行的。比如，根据腾讯公开的资料，企业微信、QQ小程序、腾讯新闻等产品，就是使用自己的无服务框架构成的微服务系统。以后，无论是通过物理机、虚拟机、容器，或者是无服务云函数，都会是微服务实现方案的一个候选项。
|
||
|
||
小结
|
||
|
||
今天是架构演进历史的最后一讲，如第1讲的开篇所说，我们谈历史重点不在考古，而是要借历史之名，来理解每种架构出现的意义以及被淘汰的原因。这样，我们才能更好地解决今天遇到的各种实际的问题，看清楚未来架构演进的发展道路。
|
||
|
||
对于架构演进的未来，2014年的时候，Martin Fowler和James Lewis在《Microservices》的结束语中分享的观点是，他们对于微服务日后能否被大范围地推广，最多只能持谨慎的乐观态度。无服务方兴未艾的今天，与那时微服务的情况十分相近，我对无服务日后的推广也是持有谨慎的乐观态度。软件开发的最大挑战就在于，只能在不完备的信息下决定当前要处理的问题。
|
||
|
||
时至今日，我们依然很难预想在架构演进之路的前方，微服务和无服务之后，还会出现什么形式的架构风格，这也正契合了图灵的那句名言：尽管目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。
|
||
|
||
|
||
We can only see a short distance ahead, but we can see plenty there that needs to be done.-
|
||
尽管目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。-
|
||
—— Alan Turing, Computing Machinery and Intelligence, 1950
|
||
|
||
|
||
一课一思
|
||
|
||
在这一讲之前，你是否了解、接触过无服务架构？无服务目前在中国处于起步的发展阶段，阿里云、腾讯云的无服务计算框架，都给了普通用户相当大的免费额度，你愿意去试一下吗？
|
||
|
||
欢迎你在留言区分享你的看法。如果你觉得有收获，也欢迎你把今天的内容分享给更多的朋友。
|
||
|
||
|
||
|
||
|