频道栏目
首页 > 资讯 > 其他综合 > 正文

软件发展概念解析

16-11-14        来源:[db:作者]  
收藏   我要投稿

这些年,软件在发生什么变化?

过去 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 倍的开发效率,干不干?

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

为什么要打破当前的 Monolithic 软件模式?

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

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

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

CBB 组件应用了这么多年,为什么现在提服务化,是噱头,还是救命稻草?

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

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

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

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

容器和微服务是什么鬼?

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

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

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

微服务是支持 DevOps 的革命性架构,使系统改变的成本很低,但微服务间的协调是一个十分复杂的工程,需要自动化工具配套。

相关TAG标签
上一篇:台积电:绝大多数7nm客户都会转向6nm_IT新闻_博客园
下一篇:最后一页
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站