▼

软件不像硬件，看得见，摸得着。硬件规格是数据化的，清清楚楚。软件没有这么直观，要把软件讲清楚不是件容易的事情。听软件大师们讲软件，抽象、建模、分层等等，也很难懂，却又不敢质疑，但很多情况下就没有这么幸运了。所以，还是要设法把软件通俗易懂地讲出来。这里针对大家关心的一些软件问题做个尝试，以我对软件的一知半解，尽量以科普化的语言来探讨。

过去 10 年，硬件的计算能力提升了 100 倍。软件发生了什么变化？软件开发语言从早期的 Basic、Fortran、C，到现在的Java、C#、Python、PHP，当前常用的开发语言不下百种。软件新技术也层出不穷，XaaS、开源、容器、服务，等等。和硬件不断提升处理能力相比，软件的发展主线是什么？

这 10 年来，软件代码量至少增加了 100 倍。软件技术发展的主线，就是不断提升软件开发效率和开发者体验，不断降低软件开发入门门槛，让越来越多的人参与到软件开发，不断提升软件生产力。软件生产力的快速发展，也带动软件生产关系的不断发展，比如开源。和硬件发展的 Scale Up，软件发展天生就是 Scale Out。要说构建生态圈这种能力，软件绝对是一流的。互联网软件正是把握这个规律，不断应用最新的软件开发技术和开发模式，不断降低软件的生产成本。

我们当前的编程语言和编程方式，16 年来几乎没有变化。从开发能力上讲，是没有跟上软件发展脚步的。

什么是嵌入式软件？早期对嵌入式软件的理解，就是嵌入在硬件系统中，和硬件耦合很紧，随设备一起销售的软件。十多年过去了，从概念定义看，无线软件仍属于嵌入式软件范畴，但自从 Linux 从 PC/服务器端移植到嵌入式环境后，嵌入式软件也在发生变化，和普通的 PC、服务器软件开发环境相比，技术上没有本质区别。从下面的对比可以更清晰地看出来：

嵌入式软件和互联网软件真正的区别在商业交付模式和运营模式。既然在技术特征上没有太大区别，互联网软件上很多好的开发方式就可以用在嵌入式软件。比如互联网软件开发的 SDK+IDE，大量代码都可以自动生成，对效率的提升不是一点点。遗憾的是 SDK+IDE 在我们当前的软件开发中用的很少。开发一套好的 SDK+IDE 很难，并且很多人对 SDK+IDE 自动生成代码的成见是资源消耗大、性能差。这些认识都已过时，即使如此，以 1% 的性能损失换 10 倍的开发效率，干不干？

千万不要自认为是嵌入式软件而停止前进的脚步。嵌入式软件发展的方向也是要提升软件开发效率和开发者体验。

人们常用澳大利亚 Ayers 巨石来形容单体 (Monolithic) 软件。高 348 米，长 3000 米，周长 9.4 公里，对一块石头来说是壮观的，但对软件来说并非好事。Monolithic 软件，每个单元上运行的软件都是一个不可分割的整体。在这个整体中，要优化一个性能，要增删一个特性，必须编译整个版本、验证所有的用例、交付升级整个版本。客户说要增加一个窗户，而我们总是每次给客户整幢大楼。

我们当前的开发组织一般都是按模块来划分的，比如 OM 组、信令组、小区管理组、算法组等。组和特性是完全交织的关系。比如开发一个 HSPA 特性，需要平台组、OM 组、传输组、信令组、小区管理组、算法组都要参与，都要修改。反过来看，每个组几乎和所有的特性都有关系。这种网状关系导致修改特性的影响、故障的扩散范围根本不可知。每个开发者修改代码花的时间并不多，大量的时间发生在等待和验证。除了验证自己开发或修改的特性之外，还要等待别人的缺陷修复，还要验证自己的修改不影响其它特性。这就是当前程序员痛苦的根源。

有没有可能控制修改特性中故障传播的范围？有，我们要打破 Monolithic 软件模式。

为什么提从组件化到服务化？要回答这个问题，先要理解什么是服务。学通信的，Service 这个词最令人费解。服务 or 业务？几乎在不同的场合，就有不同的含义。举个例子就比较容易理解了，华为公司使用外包人员有两种方式：一种方式是把外包人员直接放到华为公司，由华为负责外包人员的工作安排、输出监控、绩效管理。这种方式看起来直接、效率高，但也有缺点，就是华为公司要负责外包人员的管理、衣食住行甚至思想动态。哪天某个外包人员出点啥事，华为公司也要负责。

另一种方式是外包人员交由外包公司来管理。华为向外包公司提业务和质量需求，外包公司用多少人、怎么做，华为公司都不管，把事情搞定就行。这种方式前期可能麻烦些，但后续麻烦少，可替换性也很强。华为公司想换一个外包公司也很容易，甚至可以并行找不同的外包公司做备胎。第一种方式就是组件化，第二种方式就是服务化。

组件化是初级的复用手段。把公共的功能做成二进制组件，供不同的产品调用。避免重复开发，提升开发效率。组件化发展到现在，缺点也很明显。比如相同的 VPP 组件，无线几乎所有产品都要用，每个产品都要对它进行适配、资源管理和操作维护管理，额外的开销还是很大。并且产品很容易被 CBB 组件绑架，一旦用了某个平台或组件，就很难换了。组件化的缺点就是服务化的优点。服务化改造后，自己的数据信息自己管理，对外提供易用的服务接口。使用方只管功能，不用关心内部实现，不用去适配、管理组件的运行环境、资源，并且替换比较容易，跨平台迁移几乎是零成本。这对于被厚重平台绑架的产品来说，绝对是一个福音。

服务化天生的复用性好，耦合性低，自治性强。用好了是提升效率的一个手段。华为当前外包模式希望切换到 FP，不谋而合啊。

当前 Docker 容器比较火，以至于很多人认为容器是 Docker 发明的。其实容器就是一个程序的运行环境。在 20 多年前就有了，一直不温不火，最近容器又爆红，有取代虚拟机之势，主要是因为 Docker 在容器内提供了一个开发环境和部署方案，让开发者更容易利用容器来开发和部署自己的应用。应了上面那句话，降低门槛就是提升生产力啊。

“微服务”和“服务”一字之差，事实上是有较大差异的。在实现层面，组件化强调对复杂系统分而治之，降低整体复杂度，但没有强调数据信息的自治和功能的易用性。而服务化在诞生初始，只强调通过易用的服务化接口打通企业内应用，异构软件能共存，忽视了对服务内部实现方式的定义。微服务则综合了组件化和服务化两者的优点——应用按足够小的服务粒度进行分解，独立开发，启动轻便，快速开发、快速测试。每个微服务根据自身特点分配计算与存储资源，并且可独立伸缩、新陈代谢。

微服务的故障隔离能力好，服务间不影响，每个服务可以在任何时候被修改或升级，不影响其它服务。开发者减少相互的等待和依赖，自主性更强，体验更好。看起来不错啊，是打破 Monolithic 的一个利器。技术上已经通过验证，正在商用产品落地。行与不行，快见分晓了。

微服务是支持 DevOps 的革命性架构，使系统改变的成本很低，但微服务间的协调是一个十分复杂的工程，需要自动化工具配套。华为无线工具部已经启动相关工作，大家尽情期待哦！