现如今,云服务在每个月都会大概收到1x10e16次的接口调用。这一巨大的变化改变了软件的开发模式。我们已经通过复用软件中的接口和开源来完成我们一部分的梦想。对我来说这已经是一个很大的进步了!当你现在去回顾一下供我们使用的接口类型和开源项目时,你惊奇的发现只是基于些许的通用函数调用可以让我们在应用中看到无限的自由度。
许多年来,工程师们已经推动了创建组件软件的实践。达成软件工程上这个巨大的目标唯一动力开始是想要找到某些方法去获取更高的效率但是最后变成了所有软件都可以通过引用越来越高层级的抽象去完成开发。很不幸,复杂度和较低的社会共识限制了组件化的成功就例如 SOA
。组件化这个方案已经不能够满足于现在的日益增多的复用了。
现如今,随着我们已经把接口作为服务迁移到云服务上去了之后,我们也希望把组件作为接口后的一部分代码或者多个组件和其对应的接口组装成对应的接口服务。常用的组件都是开源软件项目或者开源项目的组件都是在一个有独自接口的可复用服务。这个接口可以使公有的或者私有的,它可以存在云或者被本地设施但是关键在于复用性的元素是接口和开源的组件。
这些新的组件相比 CBSD
(基于软件开发的组件)有着不同的需要。我把这些新型组件称谓组件即服务。接口都是组件即服务,但也可以是任意开源项目或者内部开发的软件都可以是一个 Caas
组件。当然了,对于 Caas
来说更为技术性细节来说是一个更加大的组件化模式的进步。如今,我们在云上提供组件并且通过服务形式提供。这个已经是一个重大的成功并且你不得不去在你设计任何内部用还是外部使用的组件尽量得让组件符合我下面提到的标准。
有一段时间可复用的片段被收录到编程语言中作为内置能力或者动态装饰,注释,库。再以前的编程语言例如 APL
, SNOBOL
里含有许许多多对的预定义的函数能并运用这些特殊的组件去提高编程速度。
在从前有一个标准语言和用于存放可复用的代码片段的函数库的念头被认为更加重要。
这一理念已经进化到框架概念中。最新版本的 JAVA
在通用 JAVA
构成的机器上应用不同的编程语言的可能已经在某些新的特定用途的语言构造实现,但是以前的编程语言仍然存在需要补充的地方。但是我们页看到新的编程语言的勃发例如 SCALA
,RUBY
,GROOVY
,PHP
...
在过去的15年中,开源发展的已经对复用能力和软件工程的开发效率提升和创新有着巨大的影响。暂时没有一个标准的方式去规范包里面开源的技术。开源能力的影响力极大程度上依赖于把这个能力合入自己项目时的能力,就让开源项目有了更加大的动力去促进复用和简化复用。
我们看到所有的这些都指引着我们努力去把可复用格式上的包技术并且让其变得更加容易添加到软件中,更频繁的使用并且加大其他软件使用的概率。
在这边博客中,我尝试让大家理解需要构建组件用于在服务中复用并且可以称为基于云的组件即服务的框架。
从历史的角度上来看,
技术上,一个组件需要满足原生云或者可用的组件即服务包括上面提到的4点的所有资格。
Docker
PAAS
,云如今,软件应用可以在通过测试之后都是被瞬时部署或者利用 Paas
或开发配置的软件进行近乎瞬时部署。通常情况下开发配置打包软件应用的方式都封装在一个“容器”当中。在某些情况下,容器的价值在于简化了分离开来的代码块的安装和把一个服务互相依赖的部分封装成一个容易管理的单位模块。容器经常会在实例化的时候注入不同的实例依赖,所以实例可以不用考虑任何物理限制在任何地方即时创建。
容器通过限制,即使同一机器上没有其他容器在运行,使某个具体服务可能产生的错误描述只在容器内部发生,从而帮助隔离特定服务可能引入系统的错误。
一个组件可以包含许许多多的组件,例如 OSGi
和 Docker
,每一个容器都提供某些保护和函数能力。
组件应该被设计为可以通过接口管理系统管理的方式。做这件事的价值是显而易见的。
我们已经进入到一个软件开发的崭新时代,在这个时代软件应用极大部分是由开源的组件或者基于其他组件的接口组成。只需很低的成本和更快的时间,就可以像气泡一样,一个又一个的更加有潜力更加让人惊叹的应用,服务和加强后的函数能力浮现出来。如果我们可以在那个开发周期长,总是有bug,很少能被解决的旧时代打成构建组件即服务的共识,我们就可以把那个旧时代转变成现如今的变化激烈,低成本,周期短的新时代中来。这很值得我们去思考是否应该要通过现在强有力的组件即服务接口来构建或者重构现有软件应用。