接口和组件作为一个服务--梦想成真
现如今，云服务在每个月都会大概收到1x10e16次的接口调用。这一巨大的变化改变了软件的开发模式。我们已经通过复用软件中的接口和开源来完成我们一部分的梦想。对我来说这已经是一个很大的进步了！当你现在去回顾一下供我们使用的接口类型和开源项目时，你惊奇的发现只是基于些许的通用函数调用可以让我们在应用中看到无限的自由度。
许多年来，工程师们已经推动了创建组件软件的实践。达成软件工程上这个巨大的目标唯一动力开始是想要找到某些方法去获取更高的效率但是最后变成了所有软件都可以通过引用越来越高层级的抽象去完成开发。很不幸，复杂度和较低的社会共识限制了组件化的成功就例如 SOA。组件化这个方案已经不能够满足于现在的日益增多的复用了。
现如今，随着我们已经把接口作为服务迁移到云服务上去了之后，我们也希望把组件作为接口后的一部分代码或者多个组件和其对应的接口组装成对应的接口服务。常用的组件都是开源软件项目或者开源项目的组件都是在一个有独自接口的可复用服务。这个接口可以使公有的或者私有的，它可以存在云或者被本地设施但是关键在于复用性的元素是接口和开源的组件。
这些新的组件相比 CBSD （基于软件开发的组件）有着不同的需要。我把这些新型组件称谓组件即服务。接口都是组件即服务，但也可以是任意开源项目或者内部开发的软件都可以是一个 Caas 组件。当然了，对于 Caas 来说更为技术性细节来说是一个更加大的组件化模式的进步。如今，我们在云上提供组件并且通过服务形式提供。这个已经是一个重大的成功并且你不得不去在你设计任何内部用还是外部使用的组件尽量得让组件符合我下面提到的标准。
关于复用的简史
有一段时间可复用的片段被收录到编程语言中作为内置能力或者动态装饰，注释，库。再以前的编程语言例如 APL, SNOBOL 里含有许许多多对的预定义的函数能并运用这些特殊的组件去提高编程速度。
在从前有一个标准语言和用于存放可复用的代码片段的函数库的念头被认为更加重要。
这一理念已经进化到框架概念中。最新版本的 JAVA 在通用 JAVA 构成的机器上应用不同的编程语言的可能已经在某些新的特定用途的语言构造实现，但是以前的编程语言仍然存在需要补充的地方。但是我们页看到新的编程语言的勃发例如 SCALA，RUBY，GROOVY，PHP...
在过去的15年中，开源发展的已经对复用能力和软件工程的开发效率提升和创新有着巨大的影响。暂时没有一个标准的方式去规范包里面开源的技术。开源能力的影响力极大程度上依赖于把这个能力合入自己项目时的能力，就让开源项目有了更加大的动力去促进复用和简化复用。
我们看到所有的这些都指引着我们努力去把可复用格式上的包技术并且让其变得更加容易添加到软件中，更频繁的使用并且加大其他软件使用的概率。
在这边博客中，我尝试让大家理解需要构建组件用于在服务中复用并且可以称为基于云的组件即服务的框架。
组件即服务定义
从历史的角度上来看，
- “一个软件的组件是一个预定义好的特殊接口和依赖于特定的上下文的组成单位。一个软件组件可以独立部署并受制于第三方的架构” 软件中组件的定义已经被改变并且已经扩展成一个模糊的概念。基于软件工程的组件在面向对象的编程中被创建并且已经过时了。这一演变反应这我们对如何复用软件的认知的提升。举个栗子，我找到更加实际的定义：
- 2.完整记录
- 3.全面测试
- 健全的-通过全面的合法输入校验
- 拥有回传合适的错误信息或返回码能力
- 4.设计成可以被放到未预料到的场景下使用
技术上，一个组件需要满足原生云或者可用的组件即服务包括上面提到的4点的所有资格。
文档和使用要求
- 依赖必须清楚的表达并且这些应用的依赖的版本也需要清晰展示出来
- 一个组件接口应该简单明了的展示如何使用。如果是复合接口应该提供复合使用的标识或者类给使用方
- 所有组件接口都应该被文档记录并且发布到一个公共仓库中供所有使用者或者该组件的潜在使用者去查看和评论。私有接口应该只对私有用户可见但也应该被文档记录并发布
- 一个组件的接口可能会在需要的情况下频繁改变，有时候会更加频繁。使用者应该对所有的这些更改在合适的时机提前告知并且支持高优先级接口应该兼容之前的逻辑
- 一个组件的所有接口应该被文档记录并且通过观察可以通过日志文件或者组件的事件流跟踪对应调用方法
- 一个组件的内部数据都应该在组件内部可以被调用，并且组件的接口应该是公共的或者是私有的
系统需求
- 组件必须把不同订阅者的数据以一种比较好的定义方式去分离
- 一个组件应该具有同时存在多个实例操作的能力
- 一个组件对错误的容忍限度应该被明确指出
- 一个组件应该可以被打包到一个标准的容器内如
Docker - 一个组件应该遵从被使用的应用规范
- 遵从标准的安全格式或者以一种良好的定义方式结合到安全系统中
- 测试版本的组件应该可以可以被需要进行测试的用户在他们自己的函数体内调用
- 组件的服务级别协议在生产环境中的服务应该被发布或者可被调用
- 一个组件不应该依赖任何具体的网络地址，文件系统地址或者其他物理世界的依赖，但是应该虚拟化并允许在调用或者实例化的时候注入现实世界的依赖
容器，组件和 PAAS，云
如今，软件应用可以在通过测试之后都是被瞬时部署或者利用 Paas 或开发配置的软件进行近乎瞬时部署。通常情况下开发配置打包软件应用的方式都封装在一个“容器”当中。在某些情况下，容器的价值在于简化了分离开来的代码块的安装和把一个服务互相依赖的部分封装成一个容易管理的单位模块。容器经常会在实例化的时候注入不同的实例依赖，所以实例可以不用考虑任何物理限制在任何地方即时创建。
容器通过限制，即使同一机器上没有其他容器在运行，使某个具体服务可能产生的错误描述只在容器内部发生，从而帮助隔离特定服务可能引入系统的错误。
一个组件可以包含许许多多的组件，例如 OSGi 和 Docker，每一个容器都提供某些保护和函数能力。
接口管理
组件应该被设计为可以通过接口管理系统管理的方式。做这件事的价值是显而易见的。
- 每个组件接口都是可用并且可以评论和提升的
- 如果需要，可以在使用过程中跟踪每个组件，以了解其使用方式和调用方以及错误解决方案
- 如果需要，接口管理既可以用来管治也可以提供组件额外的安全服务
- 接口管理可以促进版本管理和大部分上面提到的组件质量服务需求
总结
我们已经进入到一个软件开发的崭新时代，在这个时代软件应用极大部分是由开源的组件或者基于其他组件的接口组成。只需很低的成本和更快的时间，就可以像气泡一样，一个又一个的更加有潜力更加让人惊叹的应用，服务和加强后的函数能力浮现出来。如果我们可以在那个开发周期长，总是有bug，很少能被解决的旧时代打成构建组件即服务的共识，我们就可以把那个旧时代转变成现如今的变化激烈，低成本，周期短的新时代中来。这很值得我们去思考是否应该要通过现在强有力的组件即服务接口来构建或者重构现有软件应用。
