55 | 云盘算、容器革命与服务端的将来

到本日这一讲，我们服务治理相关的话题基本上接近尾声。通过前面的内容我们可以知道，服务治理比软件治理要复杂很多。它的涉及面非常广，需要有系统性的、结构化的解决方案，需要底子架构、中间件、SRE 工作平台等多个条理、多个工种之间的精密配合。
软件的服务化过程本身是互联网的胜利。从最初以泛娱乐场景为主，到本日影响国民经济的方方面面，场景越来越严厉和多样化。
软件服务化使得工程师有了新的职能：on call。软件工程师并不是把软件开发出来就完了，还需要保证软件上线后的服务品格，好比稳定性。在线上出问题的时候，软件工程师还需要随时相应线上的 on call 请求，参与到故障排查的过程中去。
但是提供靠谱的服务是云云之难，尤其在软件并不是自己团队开发的情况下，保证服务质量的过程增长了许多不可控的因素。
云盘算的诞生，是一次软件交付方式界限上的重新界说。在此之前，IT 技术供应商通常的交付物是可执行程序或源代码。这种交付方式更多的是软件功能的交付，但是并不参与到软件线上的运行状态的管理。
云盘算界说了全新的交付方式，IT 技术供应商不再提供可执行程序或源代码，而是互联网服务。用户使用 IT 服务时并不需要了解背后运转机制。即使在线上出问题的时候，也是 IT 技术服务商安排技术职员去解决，而不是用户自己去想办法解决。
这意味着云盘算改变了用户与 IT 技术服务商之间的配合方式。从之前的对交付过程负责，到对服务的质量效果负责，两边的职责更为简单清楚。
云盘算发展到本日，大要经历了两个阶段。
资源交付革命

第一个阶段，是资源交付的云化。它的厘革点在于 IT 资源交付的效率。
在云盘算之前，业务上线过程大要上来说是这样的：
首先，购买底子的 IT 资源，好比服务器和交换机等；
然后，将服务器和交换机等通过物流系统运送到 IDC 机房并上架；
安装上底子的操作系统；
摆设业务系统。
而云盘算之后的业务上线被简化为：
购买云上虚拟的云主机若干台，这些云主机已经按用户选择预装了底子的操作系统；
摆设业务系统。
这个阶段交付的 IT 产物形态并没有发生根本性的变化，以前是物理机，如今是云主机，两者使用上的用户体验并没有很大的差异性。但这里面 IT 资源交付效率发生了巨大的变化，它主要表如今以下几个方面。
资金优化：消除了物流的成本。
时间优化：物流时间、产物自助化程度（上架、操作系统安装）。
资源复用率提升：云盘算通过将不同用户的 IT 资源聚集在一起，提升了 IT 资源的使用效率，淘汰了社会资源的浪费。
容器革命

云盘算的第二个阶段，以容器革命为标记，以 Kubernetes 为究竟标准，迭代的是服务治理的本领。
前面我们在 “47 | 服务治理的宏观视角” 提到过以下服务治理系统的模型：

服务治理系统的影响因素非常复杂。我们大要将各类影响因素分为以下几种类型。
软硬件升级与各类配置变更，即发布。
软硬件环境的故障。
终端用户的请求。比较典型的场景是秒杀类，短时间内大量的用户涌入，导致系统的承载本领超过规划，产生服务的过载。当然还有一些场景，好比有针对性的恶意攻击、特定类型的用户请求导致的服务端资源大量消耗等，都可能引发服务故障。
即使是在本日，在容器技术大范围应用之前，我们大部门公司的服务治理系统都建立在物理机或云主机的底子上。这种做法的问题在于系统的复杂性过高，不同的影响因素交织在一起，让彻底解决问题变得非常困难。
我们举配置变更作为例子。通常来说，配置变更是我们自动对系统举行软硬件升级或配置参数调解导致的，它应该被认为属于操持性的运动。
变更是故障之源。
只有操持性的配置变更才会按发布操持和查抄清单有序地执行。但是，显然各类软硬件环境的故障是非预期的，不知道什么时候会来一下。但是如果我们基于物理机来做服务治理，一定需要面临由于不可预期的软硬件故障而举行配置变更。
这种为了恢复故障的变更有更大的临时性，自然也更难形成高质量的查抄清单来查抄配置变更的靠谱度。如果线上已经通过流量调度举行了必要的恢复那倒是还好，最多是对这样的临时变更做更多的人工查抄来确保质量。
如果某种配置变更方式经常被用于某种故障恢复的场景，那么这样的配置变更就很可能被脚本化下来，以便让故障恢复过程更加高效。
这样随着时间的日积月累，我们就得到了基于物理机的服务治理系统。
但是，这种服务治理系统固然做到了很高的自动化，但是它并不能算是一个高度自治的系统。
高度自治的服务治理系统对软硬件环境的故障有天然的免疫：我们什么都不用做，系统自己完成自我修复过程。
这就是容器革命带来的变化。
本日 Kubernetes 基本已经成为 DCOS（数据中心操作系统）的究竟标准。它带来了以下告急的改变。
用户操作的对象不再有机器这玩意，最焦点的概念是服务。当然这是称之为数据中心操作系统概念的由来。
硬件资源池化。软件或服务与硬件环境解绑，可以轻松从一台物理机迁徙到另一台物理机。
面向逻辑视图描述集群状态。配置中心的数据只表现业务系统的逻辑，不表现物理特性。
当然，本日容器革命仍旧还在风起云涌地举行，完备的演进过程会很漫长。这背后的原因在于，容器技术固然先辈，但它从根本上改变了我们使用盘算力的习惯。
服务端的将来

将来服务端技术的演进会走向何方？
服务治理系统的迭代，终极将让我们到达这样的状态。
任何业务都可以轻松到达 7x24 小时不间断服务。高并发？高可用？高可靠？小菜一碟。
做业务都足够的傻瓜化。服务端工程师？不存在的，我们要的只是 SQL 工程师。
做一个新的有状态的存储中间件固然比做业务麻烦一点，但是，一方面也没有多少新的存储中间件需要做的，另一方面做一个存储中间件有足够便捷的辅助设施，也不会比本日做一个内存中的哈希表难多少。
以是在我看来，服务端工程师很有可能只是一个阶段性的历史配景下的产物。随着互联网应用开发的底子设施越来越完善，服务端开发的成本越来越低，终极和前端工程师重新合而为一。
是的，我说的是重新回到软件时期的样子。那时候，并不存在前端和后端工程师之分。
结语

本日我们聊的话题是服务端的将来。云盘算和容器革命将服务端的底子设施化推向了高潮。将来，也许我们并不需要专门的服务端开发工程师来做业务开发。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。