随着并发项目的增多，整个开发团队能力的边界其实是参差不齐的，大家对规范的遵守，以及一些公共组件的使用，实际上也是不标准的。这样会导致整个产品体系和平台体系慢慢的进行腐化，腐化到一定过程就会导致必然要采取措施对这个架构要进行重构。

在重构的过程中，会整合客户的需求。实际上自己的开发速度也很慢，会拖累整个产品的迭代速度。举个列子，阿里云把电商的一些模型也进行了服务化的框架输出，包括在阿里云上类似EDAS的服务，把电商的基础服务框架进行产品化输出之后，可以很好地支撑同行企业的快速创新和产品开发。

想进行电商业务尝试的企业，可以很快把底层的基础架构构建起来。深信服也有这样的一个基础框架叫phoenix框架。实际它是由这几部分组成，底层框架，中间件和业务应用app，最底层都是要依赖一个体系的服务框架。

在开发队伍里面，采用多进程或协程的模式，或者是微服务这样一种形态，都是属于底层服务框架。服务框架实际上是作为底层的一个插座。基于服务框架之上，可能还会依赖很多中间件，包括扩展模块，比如说整个日志的处理。

配置的管理操作，还有整个国际化翻译，包括整体测试框架的遵守，实际上是整个中间件的组成。这些中间件经过一定的封装适配之后提供标准的公共接口，开发人员只需要遵守公共接口，后台整个中间件的能力建设，由整个后台的底层框架去保障的。

基于上面来做业务需求的转化，当开发人员或产品经理接到新的需求时，实际上有开发人员只是把业务需求转化成具体的一个业务应用，它并不关心底层实际应用是多进程还是多线程。

在整个体系架构向前引进的过程中，底层是用微服务架构，还是用容器去部署，作为APP来讲实际上是解耦的。也就相当于把开发人员的角色跟整个底层框架的角色进行区分，这样的话整个业务在开发和部署速度上都会加快起来。

三、超融合aCloud+aCMP架构设计

整个Phoenix基础框架的底层，实际上把通用服务能力，比如说外部响应的这种服务能力，一些周期任务，这种RPC还有日志公共的进行一层封装，基于这个框架上进行上层APP的开发，拿到phoenix基础框架的开发人员。

第一个命令可以很快创建一个项目，第二个是创建项目之后对整个服务进行开发。如果把这个框架拿去要做一个用户管理系统，可能有一个APP是用户账号，一个是 (责任编辑：admin)