2.3.4 开发上线

设计工作完成后，就需要开发人员完成开发了。开发分为业务中心和业务应用两部分，各业务中心由单独项目团队进行开发，并为上层多个业务应用提供服务能力，但业务中心的需求又是通过上层所有业务应用的业务场景获取的。一个业务中心会支撑多个业务应用，所以在设计开发计划时，很可能业务中心和业务应用是同时开发、相互交错的关系。

各业务中心之间需要交互共同完成能力共享服务（阿里建议尽量减少业务中心之间的交互，而应该由业务应用在上层组合各业务中心的服务能力），业务中心与业务应用也需要交互调用。采用什么技术完成协作交互对于整个架构至关重要，目前主要有两种方案。

第一种方案是传统面向服务的架构（Service Oriented Architecture，SOA），采用ESB。ESB的出现是为了弥补以前建设的系统封闭、打破“孤岛”进行业务和数据的互联互通，它不关心业务系统内部是如何建设的，每个系统都自己设计、自己实施，不需要关心其他系统的业务逻辑，等系统都上线后再看如何进行对接，通过ESB实现接口的路由和集成。从架构层面看每个系统都是一个“烟囱”，ESB只是给它们的相互通信进行了技术上的支持，如果采用这种方式建设业务中台会有个很严重的问题：ESB没有业务整合的能力，数据和业务都不能下沉，也就没办法向上提供服务能力的支撑，难以实现业务在线化。还有一点，系统上线后如果不满足其他系统的调用需求，需要变更时比较困难，因为它的接口可能有多个系统在使用，很难做到接口级的适配。

基于以上分析，搭建业务中台不适合采用ESB进行建设。如我家里有天晚上突然断电了，发现是电费用完了，我赶快在微信上交了电费，等了20分钟还没来电；又在支付宝上交了电费，还是没来电；打客服电话，被告知需要在购电后一个多小时才可以。交了电费后要等这么长时间才能来电，这种极差的体验和IT架构有很大的关系。

第二种方案是目前主流的微服务架构。前文在介绍企业IT架构演化时简单介绍了微服务架构。采用微服务架构就像搭积木，每个微服务都是一个零件，使用这些零件组装出不同的形状。通俗来说，微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作、互相配合，组合成一个大系统，为用户提供最终服务。

我开发过很多传统IT系统，它们经过多年的升级、完善，可能代码达到几十万行，没有一个人能全部清楚，很多开发小组一次次在上面集成新的功能，很有可能和别人的代码发生冲突。而微服务的架构完全相反，它是将以前集成的功能模块进行拆分，把一个大应用拆分为一些小服务，这些小服务都有专人负责独立的设计、开发、测试和部署。微服务架构的特点如下。

●开发和运维灵活高效，依赖自动化。

●微服务架构将大应用分解成彼此独立的小服务，自由选择适合的实现。

●每个微服务专注于一件事，并将这件事做好，大大提高开发效率。

●微服务架构将大量工作分解成易管理、更高效的小业务单元，可根据实际需要独立进行扩展。

传统SOA和微服务架构相比，说一种比另一种优秀是不太恰当的，很多时候应该去考虑技术架构适应的业务场景。对于多种异构系统、大型复杂的综合集成项目，应该使用SOA搭建统一平台、建立统一集成标准；对于电商类、移动应用类、需求变更快类项目，使用微服务架构更加适合。有人做大集成，有人费尽心思在做拆分。“分久必合，合久必分”完美地体现了IT架构的发展趋势。

微服务架构用到各种技术组件来配合协调工作，包括服务注册发现、分布式配置中心、负载均衡、服务容错、API网关等，阿里云EDAS和SAE两个产品都已全部实现。EDAS支持三大主流微服务架构——HSF、Dubbo、Spring Cloud。零代码侵入就能完成Dubbo和Spring Cloud应用上云，可有效降低运维成本。

●基于成熟微服务框架快速构建应用。

●借助阿里久经考验的微服务框架HSF在云上构建微服务应用。

●支持原生Dubbo和Spring Cloud上云。

●无须构建ZooKeeper、Eureka、Consul等微服务依赖的自建服务，极大降低运维成本。

●内置灰度发布、流量控制、环境隔离等企业级高级特性。

微服务这种“分而治之”的方案也带来了一些问题。虽然每个服务变得简单，易开发了，但服务之间的关系更复杂多变，要处理的服务依赖更多。所以微服务“微”到什么粒度，需要根据实际情况确定，后文将在业务中台demo中基于HSF讲解实际的开发和使用。

传统项目开发完成后会生成一个运行包，例如Java的JAR或者WAR包进行服务器部署。一般的流程是开发经理写好部署操作手册，编译打包文件，拿到测试人员签字的测试报告，一起发给部署工程师；部署工程师登录准生产服务器，按照操作手册在服务器上进行操作；测试工程师在准生产环境进行验证，通过后由部署工程师在生产服务器上再次执行部署。

但是微服务化后的项目，服务被进行了细粒度的拆分，甚至一个服务就可能是一个系统，部署一次可能有十几、几十个操作手册和打包文件，以及各个服务的测试报告。每个服务都需要负载多个实例，这样下来可能需要几十台服务器才能跑起来，这对于企业的系统发布、运维压力很大，甚至靠人力是完成不了的。

解决的办法就是将上线、打包、部署流水线化，依靠CI/CD持续集成进行自动化部署。整个硬件资源、技术平台也都需要自动化的运维，靠人力是不现实的。目前我们业务中台有200多台云服务器（Elastic Compute Service，ECS）、20多台数据库服务器，没有一个专职的运维工程师和部署工程师，全靠自动化的运维和动态感知，这就是开发运维一体化。使用云效平台进行自动化流水线打包发布，使用云安全中心的SaaS产品保证安全、可靠、稳定。如果不使用云架构而用传统的IT架构，得需要更多专职运维人员三班倒进行保障。