云时代软件研发的终局猜想
导读 本文作者侯前明（花名林轩）是阿里集团系统软件资深技术专家，Sigma 调度引擎和 PouchContainer 负责人。 2009年加入阿里巴巴，先后参与了中间件、TAE的研发和系统设计工作。2015 年开始打造 PouchContainer 和 Sigma 调度引擎，并致力于推进容器化、镜像化和统一调度在阿里内部的落地和实施。本文从他对未来研发趋势的预测开始，对云计算时代软件研发终局进行了展望、猜想。
2015 年到 2016 年，是业界普遍认为的容器技术爆发的一年，短短几年时间，我们看到容器技术星火燎原。但是容器毕竟是个底层产品，距离业务还很远。对云上客户来说，直接需要的终归是直接触达业务的应用。 而在这一层上，还没有形成标准。
直接触达业务和应用的这一层在哪里？
云的直接用户是软件开发者，是程序员；并且不是系统软件编程人员，而是业务系统编程人员。
更不是产品、运营，不是 CTO，CEO。云的未来一定是围绕开发者，围绕编程人员的。业务系统编写者，直接使用的是编程语言，最终构建的是业务系统。所以比 Kubernetes 更上层的标准和体系，一定是围绕代码展开的。
这在概念上，其实已经有一些现有的标准可以类比，比如 SQL 就是一个非常伟大的标准。
有了这个标准，所有开发者，各种语言的代码，使用任何一种数据库的方式都变成一样了。
各个数据库厂商才可以放心的独自演化，新的数据库产品直到今天都在不断的涌现。
SQL 标准定义了业务代码和数据库交互的统一方式。再比如消息中间件的标准，这块相对比SQL做的差些，不够统一。
目前阿里也进来做通用的标准了。数据库和 MQ，一个同步调用，一个异步调用，再加上 RPC 服务间调用，是传统业务开发中典型的3种场景。
这也正好是最早的阿里中间件三大件 HSF、Notify 和 TDDL 诞生的三个场景。从三大件诞生，到现在，十年过去了，业务系统的开发模式并没有本质的变化，但是业务系统运行环境却逐渐步入了云计算时代。
换句话说，我们仍然在用十年前，在尚无云计算的时侯发展出来的模式，解决云计算新时代的问题。这一定是有问题的。
云计算时代的会不会演化出一种新的研发模式，这种研发模式成为直接触达业务和应用的标准？FaaS 的出现已经有点儿这个苗头了，但是还不够。因为 FaaS 目前看只能解决部分场景的需求。高质量的在线服务需要的永远是严阵以待，而不是临渴掘井。
从代码来看未来研发趋势
未来的代码会是什么样子的，云计算时代的软件研发终局会是什么样子的？
云化是未来软件研发的最大趋势，这一点毋庸置疑。不管是 PC 端，手机端还是 IoT 端，绝大多数软件都需要后台服务的支撑，来汇聚用户和沉淀数据，从而提供更好的服务。软件产品不同于实物产品，最大的特点是可以零成本无限复制，这就造成同一个细分领域的软件在充分竞争下，往往只有最优秀的实现才能生存发展下来。
所以任何最后能活下来的软件最终都要面对全球的用户和市场。这就造成软件的后端服务必须能够支撑全球用户和市场，这靠自建基础设施或局部私有云是解决不了的。所以后端服务放在云端是不可抗拒的趋势。
在这一趋势下，未来最理想的研发模式是什么，或者说 5 年后、10 年后，软件研发的形态是什么？
先看下几个发展趋势：
趋势1. 业务逻辑占比在不断提高 在软件研发中，真正专注业务本身的比例在不断提高。很多软件产品，技术变革的卖点都是在围绕这个问题，或促成这个方向。“专注自身业务逻辑，不需要关注业务逻辑之外的事情” 这句话是不是耳熟能详？
- 专注业务逻辑，不需要关注打包和依赖 — rpm、maven、gradle
- 专注业务逻辑，不需要关注对象初始化和依赖注入 — spring
- 专注业务逻辑，不需要关注页面展示和servlet流转 –- MVC 框架
- 专注业务逻辑，不需要关注通用结构和分布式逻辑 — 中间件
- 专注业务逻辑，不需要关注分布式服务的远程调用 — RPC 框架，service mess
- 专注业务逻辑，不需要关注不同 OS 的兼容，一次编译到处运行 –- JVM
- 专注业务逻辑，不需要关注构建分发及运行环境 –- Docker
- 专注业务逻辑，不需要关注服务实例，按使用付费 –- Serverless
……
这个列表还可以更长。
这个方向让开发者越来越专注业务逻辑，各种不同领域的痛点被一个个解决，让业务系统研发变得越来越高效，但是这条路远远没有走到尽头。在云计算时代，我们需要在这个方向上给出云计算时代特点的解法。
serverless 和 service mesh 都有点儿这个意思了，我们还能不能更进一步？
趋势2. 代码规模越来越大 Linux 代码量已经从最初的1万多行发展到了现在的2千多万行。越是往底层的软件产品代码规模越大，代码规模越大意味着协作范围越广。规模达到一定程度，靠单个公司的人力是无法完成整体维护和演进的。比如 Kubernetes 的代码规模，已经从最初 0.1 版本 release 时的 26 万行，到了现在 1.11 版本的 227 万行。
Kubernetes 现在有多达近 2 千个的贡献者，整个 CNCF 社区有 2 万多名贡献者。这意味着，底层系统的共建和协作规模会越来越大。技术栈会越来越向标准和一致的方向演化。
另一方面业务系统的开发者，不可能有精力去深入下层系统，或者去 DIY 一个平台。面向业务系统开发者的这层边界会越来越清晰，并且越来越重要。
另外随着软件栈代码规模的扩大，单机开发和调试，最终将会被远端云上的开发和调试取代。当云上的编译迭代速度，自由灵活度，代码关联能力，代码优化能力超过线下时，可能绝大部分开发，不管是系统软件，还是应用软件都会在云端进行。
趋势3. 编程语言从低级语言向高级语言发展 编程语言经历了从最初的汇编语言，到以 C 语言为代表的系统语言，到以 Java 为代表的面向对象语言，到以 Python 为代表的动态语言，大体经历了从低级到高级发展的过程。下一步必然是抽象度更高的面向领域的语言。
但是面向领域语言多年来并未看到非常成功和通用的案例出现。Google 在用 100 行重写一个搜索引擎，也许就是这方面的尝试。那么我们能否设计出一种云计算领域的语言，200 行搭建出一个淘宝？ 或 100 行搭建出一个滴滴后端？
云时代软件研发的终局猜想
综上所述，服务端云化的大趋势，加上研发上的3个趋势，最后的终局很可能是如下面貌：
1.从开发者的角度看：Cloud as a Computer（CaaC）
用户的开发环境完全放在云端。云端维护了完整的测试环境，日常环境，预发布环境和正式环境，提供完整的 CICD 流程；开发者使用云 IDE，和云厂商提供的 SDK 来开发业务系统代码，基于云端的代码库，通过云端编译和调试。再通过云端 CICD 完成研发到部署的闭环。
简单来说，云厂商不仅仅是提供了一个云端的研发机，还提供了一整套研发工具，内置特定于云的 SDK，以及一整套云端的单测环境，联调环境。同时能够和构建部署，预发灰度等流程无缝衔接。让研发者做到 Develop on Cloud；研发者的 PC 仅仅作为一台终端，并且不再需要额外的测试资源。
云厂商通过研发部署全生命周期的最优体验，提升研发效率，为用户创造高效迭代的价值，从而提高用户黏性。云上研发像本地研发一样流畅，并且比本地研发体验更好，更高效，更标准，更一致。
比如云端代码优化，自动扫描发现 bug，用机器学习帮助用户识别逻辑错误和系统性风险，提升研发质量，用分布式能力缩短编译时间等等，可以做的优化非常多。未来云时代的研发模式可能和今天完全不同，拥有更高的研发效率，更快的迭代速度，更完善的质量控制。
更进一步，开发者可以把云看做一台有无限多核的 CPU、无限内存和磁盘的超级计算机。在这台超级计算机上可以起任意多的进程，不同的进程可能实际运行在同一台物理机上，也可能运行在不同的物理机，但是因为高速的云端网络，用户可以透明地把他们当做本地进程一样处理。在云上搭建分布式应用就像在单机调测起多个进程一样方便。
2.从业务系统看：Elastic Architecture Hosting Service(EAHS)
云厂商能够提供的终极产品形态是“弹性架构托管服务”。任何有一定规模的业务系统，必然有其内部的系统架构，由各个子系统协作完成整体业务功能。
云厂商能够将整个业务系统当做一个整体托管在云端，通过完善的日志分析、监控告警、流量分析和预测，保证其各个子系统能够在需要的时候弹性扩缩，以最佳的配比应对业务流量。
同时和 CaaC 的开发模式无缝集成，能够通过完善标准的流程，在云端研发和更新各个组件，控制每个组件的各种颜色发布(蓝绿黄灰)，客户购买的不再是一台台虚拟机，而是整体的业务系统托管服务。
具体形式比如客户按云厂商要求的格式提供一份定义文件，文件中定义了业务系统的整体部署结构，每个部署单元对应一份代码地址，代码地址中包含了对代码的构建，运行方式和外部依赖注入的完整描述，包括服务订阅和发布，结构化存储、消息队列服务等。
云SDK能够根据这份定义文件在单机启动整个业务系统来给用户做调测；云平台能够根据这份定义文件，在云端启动整个业务系统架构。
用户不需要指定每个部署单元的实例个数和资源需求，只需指定是否支持水平扩容和垂直扩容。云平台根据接入流量和系统运行状况自动对某些部件做弹性扩缩，包括水平方向服务实例的增减，和垂直方向单实例资源的动态伸缩。
简单来说，用户只需设计好业务系统的结构，写好每个部署模块的代码提交，剩下的一切事情都由云平台完成。用户只需专注业务系统的构建和业务逻辑的实现。不必再花时间在通信问题、单点问题、数据库维护问题、灰度问题、弹性问题、容灾问题、DNS 问题，CDN 问题，运维问题。
云既然做系统，就一揽子系统化地将所有的系统问题解决掉，让每一个客户只保留业务系统开发者，足矣，不再需要 CTO、架构师和 SRE。
更近一步,在这种形态下，业务系统定义文件完全可以演化为一门云计算的领域特定语言(Cloud DSL); 对于单台电脑来说，ELF 格式定义了可执行文件被 OS 加载所需要的各种信息和数据，一个 ELF 格式的文件可以被 OS 加载启动为可调度的一个进程。
业务系统定义文件，或者用 Cloud DSL 编写的文件，就是 Cloud 这台 Computer 上的 ELF 文件，可以直接被 Cloud 加载启动为一个业务系统弹性架构实例。
3.从云厂商运维运行看：The Datacenter as a Computer(DaaC)
从云端资源管理看： Datacenter as a Computer；所有数据中心的所有物理机像一台电脑一样，任何一个业务的运行实例可以跑在任何一台物理机上。
所有的资源形成一个巨大的资源池，不同业务可以最大程度地在时间和空间上复用和互用。
自动化的异地容灾，异地多活能力，存储计算分离，不同优先级混布，各个维度各个层次上提升整体的资源利用率。
资源互用的能力跨域不同技术栈，不同部门，不同公司。
当双11过去之后，抵抗峰值的机器能够迅速被消化而不再需要消化几个月，表明资源互用的能力已经能够跨越不同的行业，并且能够通过运营协作等手段，比如再造一个零售之外其他行业的双11等等，来调节不同行业的错峰运行。
云真正成为社会的公共资源，具有宏观调控能力，从而能够大大节约整个社会的成本。
阿里集团 2015 年底就对外宣布启动阿里巴巴集团 2018 年中台战略。战略定义为，构建更具创新性、灵活性“大中台、小前台”组织机制和业务机制。其中，前台作为一线业务，更敏捷更快速适应市场；中台将集合整个集团的数字运营能力、产品技术能力，对各业务前台形成强力支撑。
有横向的技术中台来 support 几十个业务 BU 的底层技术需求。我们系统软件事业部近几年来做云化、混部项目实施的过程和实践证明，每次资源池合并之后的资源互用都会带来巨大的成本节约，包括物理成本和运维成本，这已经成为绝大多数人的共识。
注：本文转自公众号阿里系统软件技术，经阿里系统软件技术授权发布。