极客时间已完结课程限时免费阅读

55 | 云计算、容器革命与服务端的未来

55 | 云计算、容器革命与服务端的未来-极客时间

55 | 云计算、容器革命与服务端的未来

2019-11-08 许式伟 来自北京
《许式伟的架构课》
课程介绍

讲述：丁伟

时长09:01大小8.23M

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

资源交付革命

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

容器革命

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

服务端的未来

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

结语

今天我们聊的话题是服务端的未来。云计算和容器革命将服务端的基础设施化推向了高潮。未来，也许我们并不需要专门的服务端开发工程师来做业务开发。
如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们将对 “服务治理篇” 这一章的内容进行回顾与总结。
如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。
分享给需要的人，Ta购买本课程，你将得20元
生成海报并分享

赞 12

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
54 | 业务的可支持性与持续运营
下一篇
56 | 服务治理篇：回顾与总结
unpreview
 写留言

精选留言(18)

  • 有铭
    2019-11-08
    服务端越来越标准化，意味着对个人的要求变低，因此，个人靠自身才能进行议价的能力变低了。相反，前端工程师因为直接面对业务和客户，议价能力变高了。这是这个时代的特点。我这么说，并不代表前端就比后端好，其实前端的标准化也在逐步进行中，工程师在开发中起的作用是在逐渐降低的。这意味着议价能力的降低。程序员一定要记住自己和上个世纪的手工业工人没区别，能议价完全是因为手工业自身的难以标准化和复制，所以一旦这种难以标准化被技术本身打破，程序员在这个领域基本就会沦为流水线工人。所以程序员如果不想沦为流水线工人，就必须往不能标准化的地方迁移自己——当然，如果你的目标是管理一群程序员给自己干活，那你就一定要想法设法的标准化，以提高自己作为管理者的议价能力^_^
    展开
    共 4 条评论
    52
  • humor
    2019-11-25
    许老师好，您的意思是未来服务端开发工程师就要失业了吗？那如果未来前端的基础设施也完善了，比如出现了一个超智能化的语言，前端工程师不是也要失业了？那到时候互联网行业是不是只剩下产品经理和云服务商了呀……但是各个公司的业务总归是各不相同的，怎么才能真正做到所有的业务都能标准化呢？ 那我们现在这些java开发要不要转到前端去呀，纠结担忧中…

    作者回复: 业务大部分在前端，这个是基础设施做不了的，前端不可能失业

    共 6 条评论
    6
  • lightSky
    2020-10-23
    服务端基础设施越来越完善，前端也一样，很多基础sdk，框架都很成熟。不妨换个角度看，无论前端还是后端，都是服务于业务，如果你能对某个领域的业务很精，再以技术的手段赋能业务，应该是个很不错的方向，即业务领域专家，当然前提是这个业务相对会复杂些，有些门槛。
    5
  • 涉蓝
    2020-06-07
    那么作为一个写业务的工程师要如何做才能转向做基础设施呢

    作者回复: 对人能力要求实质上并没有太大区别，只不过基础设施岗位的需求量少，所以才显得要求高。

    共 2 条评论
    2
  • Eternal
    2019-11-30
    所以在我看来，服务端工程师很有可能只是一个阶段性的历史背景下的产物。随着互联网应用开发的基础设施越来越完善，服务端开发的成本越来越低，最终和前端工程师重新合而为一。是的，我说的是重新回到软件时期的样子。那时候，并不存在前端和后端工程师之分 老师的预测让我们感到危机了呀，十年后就失业了
    展开
    3
  • 许童童
    2019-11-08
    现在的serverless不就是向这个目标发展吗？
    2
  • BIZ_UI_3
    2022-01-05
    “服务端工程师很有可能只是一个阶段性的历史背景下的产物。”——略过武断了。基础设施的能力只能满足非功能性需求，功能性需求，即业务依然要自己开发。你当然可以直出数据完全在前端封装业务模型，你也可以全在后端做前端无脑纯展示，那能代表前端也是阶段性产物吗？无非是富客户瘦客户端的分别而已。
    2
  • Geek_88604f
    2020-08-20
    文中提到容器化带来的有以下几点：用户操作的对象不再有机器这玩意，最核心的概念是服务。当然这是称之为数据中心操作系统概念的由来。 硬件资源池化。软件或服务与硬件环境解绑，可以轻松从一台物理机迁移到另一台物理机。 面向逻辑视图描述集群状态。配置中心的数据只体现业务系统的逻辑，不体现物理特性。——个人认为这些虚拟机也具备，可能不是容器化根本的好处。容器化最重要的优势有两点：一是资源利用率高，可以进行比虚拟机更细粒度的划分，可以做到一个服务实例一个容器；二是故障迁移的速度更快，这对保障服务的SLA是至关重要的
    展开

    作者回复: 基于虚拟机迁移的是机器不是服务，配置变更也必然涉及到机器级别，不可能和硬件解耦

    共 2 条评论
    1
  • Jaising
    2020-06-05
    感谢许老师精彩的分享，很赞同你所说的软件服务化以及云计算 容器对服务端开发的变革，但是像金融、公安这种数据机密性高、数据只在局域网流转的业务场景，上云也会对他们的软件治理有很大影响 或者说 他们的软件革命又会在哪里呢？

    作者回复: 一样的

    共 2 条评论
    1
  • J.Smile
    2020-01-12
    未来已来，后端工程师入门越来越容易，天花板也没那么高，真正牛逼的也就那几个，这其中的因素难以捕捉，成功也许就是运气。
    1
  • 阿卡牛
    2019-11-08
    现在已经出现一些端倪了，未来已来...
    1
  • leslie
    2019-11-08
    老师的话让我感受颇深：课程中画图的。。。实在不懂，关于架构、系统方面基本上算是从开篇跟到现在。 做为一个一直从事DBA&&OPS的老兵确实越来越感觉服务端运维比例的大幅减少。前段时间特意去参加了一个全国大会：运维基本上都要么具有开发的能力，要么具有运营的能力，纯正的运维比例已经很低了。 服务器端工程师要求写各种脚本和工具其实就被迫具有一定的开发能力。。。当5G和未来的6G时代：也许真的。。。。
    展开
    1
  • bluedream
    2021-12-15
    失业是不可能的，岗位只会变多不会变少。不能只从技术的角度来看待这个问题，还要从就业这个大方向上来考虑问题，如果都失业了，经济怎么发展，这些平台还有谁来用 平台的作用是减轻人的工作量，并不是取代人的工作机会。平台如果把人都搞失业了，那平台也没有存在的价值了
  • Bobo
    2021-10-24
    作为偏业务的解决方案工程师，偶然入门容器技术，下一个十年，加油啦。
  • #^_^#
    2019-11-09
    也可以转向更底层的方向
  • Aaron Cheung
    2019-11-08
    难道后端都做sre 吗……
  • pines
    2019-11-08
    不想做全栈，转sre或者devops是不是也可以
  • tingye
    2019-11-08
    服务端开发难度越来越低，怪不得前端工程师都要染指，以后只有全栈（全干）工程师了