用微服务架构方式交付云服务产品

进入云服务时代以后，微服务以及新架构逐渐兴起。与传统的软件开发模式相比，互联网的云架构模式具有很大的差异性。无论是网络的基础设施，中间件，还是运行应用的模式，都产生了很大的变化。

　　在大型企业专属云及混合云模式占主流地位的情况下，如何能够更好的将我们的云产品进行专属化，解决目前云服务研发与专属化断层的问题，是我们在建设中台过程中不可或缺的一环。中台应该能够对专属云提出良好的解决方案，解决云产品专属化的问题。

面临的挑战

1、研发模式

　　我们回过头来看，在软件时代，我们的研发模式的终局其实都是奔着专属化的目标而去。传统的软件产品研发模式，从需求分析，到立项，到研发，到发布，到交付，一整套体系是朝着最终的软件交付实施而去，本身在做的就是一个可交付的独立产品。

　　而在云服务时代，讲究快速迭代、持续发布。我们的整个研发流程链条，是偏向于公有云服务的持续发布的。这也造成了在云转型过程中，我们一些流程的缺失，专属化变得很困难。这也是所有云厂商在向私有化和专属云转变过程中都会遇到的问题。

　　之前的模式，我们从顶层设计了这是一个软件产品，自顶向下进行拆解。我们根据设计的需求去生产各种模块，然后最后按照设计进行集成，组合成一个完整的软件产品，进行最后的实施交付。这种模式下，我们能够严格的构造出我们想要的产品，并且它是独立一体的。但其缺点是扩展性和灵活性差，很难应对我们现今强调的连接、共享特性，满足移动互联时代复杂多变的应用场景。

　　在互联网或者说云服务的时代，我们面对多变的需求，需要灵活的能力化的架构去构建我们的中台。提倡中台的能力复用，让我们能够快速的去应对复杂多变的业务场景。从这里看，我们的模式变成了先有各种可复用的模块的组件，然后根据各种不同的组件去生产我们需要的软件。面向能力的架构，微服务的云架构，让我们的灵活性变得更好。但随之在面对我们类似于软件交付的专属化场景时，带来的问题就很突出，也是我们之前没有很好解决的——不同型号的模块组装在一起，未必能形成我们想要的软件产品。专属化也不是简单的将原有的云服务进行私有化的部署。当然，随着服务之间依赖的复杂度增加，我们如果没有提前设计和考虑，最终也很难将其专属化。

　　2、技术复杂性

　　微服务架构带给我们的一项灵活性就是每个微服务都可以自由的采用不同的技术栈。我们可以根据服务的特点，选择最合适的语言（如 Java、Python、GoLang 等），使用最合适的中间件（如 Redis、MongoDB、ElasticSearch 等）。在云服务时代，各种技术的进步，以及开源的普及，给了我们很多“兵器”来解决新的业务问题。

　　在公有云的服务中，我们的产品要实现的是一个最大集。也就是说，我们的产品是按能够支撑最大业务复杂性和挑战去部署的。因此，我们的微服务必然会引入约来越多的组件、框架和中间件。

　　如果在专属化的时候面对的是这样的全集，那么这简直就是个噩梦！这与我们做专属化产品的交付是相违背的。我们的产品交付，需要根据不同的客户需求，以及项目的规模等，做模块的拆分以及不同的部署方式。但现今随着微服务之间的依赖越来越复杂，甚至一开始就没有做很好的专属化考虑。如果我们用这么复杂的产品去交付，可以想象，面临的将会是一个地狱般的“黑洞”。

　　就算我们有能力在原型客户那里去交付我们的专属化产品，后期也无法规模化。特别是面对客户复杂的环境（操作系统版本、服务器芯片架构、数据库），对于这些来说，我们的适配的工作量也是巨大无比。所以，如果从技术架构层面做规范化以及简化解耦，是我们要实现规模化交付必须要面对的问题。这里并不是说我们要回退到单一技术栈。现今复杂的技术栈是面对新的业务挑战及问题所必须的，但是我们必须要有调整及不同替代方案，去解决我们面对的问题。

　　3、带来的成本

　　成本其实也是由于我们技术复杂性带来的次生问题。我们产品运行时依赖的中间件越来越多，微服务拆分得越来越细。想想我们由于每个微服务独立部署带来的 web 容器（tomcat）的成本：每个 Tomcat 自身额外占用的资源会随着服务的拆分，导致部署的资源消耗成倍增长。

　　4、交付后的新问题

　　在产品交付完毕，后续客开的时候，我们的补丁如何进行管理和使用？有新功能以及问题修复的时候，如何进行升级包的产出？现有的专属云产品的交付方式，能否有一个统一的标准？即使每个产品都有手册文档，顾问以及实施人员在实际交付的时候，需要的学习成本依然成倍增加怎么办？

　　所以说，如何降低交付实施的成本，也是我们需要解决的问题。这要求我们提供一套规范，根据规范能够通过标准化的方式进行部署实施，以及后续的升级维护操作。

解决方案

　　要解决目前我们专属化时面对的问题，最重要的一点肯定还是要认识到我们产品形态及面对客户的复杂性，从产品及架构设计上就应该把如何更好的进行专属化作为我们研发设计的一个特性重点。

　　1、服务合并

　　大部分我们面临的问题，都是由于服务规模的扩大导致的。无论在部署的复杂性上说，还是在对资源的消耗上说，都是如此。所以从设计上，我们需要去 review 我们现有服务的设计是否合理，拆分的粒度是否过于细致，导致了不必要的复杂性。考虑一下，如果只有一个 war 包，那大部分的专属化问题其实也不存在。这部分从业务和产品设计，结合我们推行的 DDD 服务设计，逐步进行我们的服务重构，目前中台架构部联合研发部也在推进这方面的建设，包括从架构 review 上进行梳理。

　　架构上的推动是说我们从代码层面对程序本身的调整。另一方面，我们也要思考如何在微服务的拆分已经合理的情况下，根据我们专属化项目的不同，进行动态的调整，以适配不同环境的实际需求。

　　为了做服务的合并，我们需要解决以下几个问题（暂不考虑编程语言和框架的差异，目前主流的方向是 Java 以及 Spring 框架）：

　　1.Java 的依赖包版本统一；

　　2.服务调用框架的统一；

　　3.基础编程框架的统一（日志、上下文传递等等）；

　　4.配置统一管理

　　这也是我们在关键服务和应用上大力推动中台规范的原因。在核心层面一致，有了统一的底座之后，我们就有了基础可以从工具自动化层面去统一解决一些问题。

　　目前在基于中台发布的微服务工程规范，以及使用统一的基础组件的情况下，我们做了一些不同的尝试，包括从 iris 服务调用框架层面支持服务调用的动态切换，可以自动发现服务方式的改变。当我们的服务发布者和消费者在一个应用内部的时候，自动将远程的调用切换到本地。目前成本比较低的一种方法，在考虑到我们服务本身还没有特别复杂的情况下，其实我们可以进行工程的合并，通过配置文件进行控制，在构建时进行不同服务的构建。这样在进行专属化时，我们可以通过一个“全功能”的配置文件，构建或者加载出一个全能的服务，做到降低部署复杂度的作用。这样做的一个好处是由于代码的统一，上述的基础框架问题能够得到很好的解决。并且在团队不大，服务复杂度没那么高的时候，能够取得非常好的效果。

　　2、如何优雅降级

　　我们也可以从如何降低我们的技术复杂性，简化我们的依赖入手。其实深入来看，这和我们目前线上遇到的稳定性问题是一致的，就是如何让我们的服务做到优雅降级。一些人可能认为，优雅降级是能够保证我们线上服务的可用性，而且可以做到出现问题时快速恢复系统。但是其实深入来看，当我们在进行专属化部署的时候，如果我们能够通过开关进行服务功能的降级，这样其实在另一个角度说，也就降低了我们的复杂性。

　　例如，在进行我们产品专属化的时候，由于面对的客户规模不是那么大，我们是否可以不依赖于缓存，将 redis 进行降级，直接使用数据库操作就可以呢？我们依赖的服务挂掉的情况下，我们是否能够提供客户端容灾方案，使得业务主流程能够进行下去呢？

　　这其实跟我们可以进行产品模块的分拆是一致的，可以让我们从技术上将不需要的模块去除，而不影响我们其他功能的使用。现实情况往往是很多的产品是“铁板一块”：从产品形态上看是做了模块的划分，但是实际实现逻辑上却没有很好的划分，导致拆分之后依赖有问题，进而影响整体功能。

　　随着云融合的推进，以及我们对服务稳定性的要求，已经逐步在推进对于服务的降级及强弱依赖的设计，在架构 review 层面对关键服务的稳定性保障措施已经在展开。结合我们链路日志以及配置中心等基础组件的推进，我们可以从基础平台层面去推动做一些自动的依赖分析和风险识别，帮助我们的应用服务去识别出问题点，逐步去完善。

　　在架构层面，我们也在推动针对我们的不同场景，给出我们技术组件及中间件的替代解决方案。例如如何能够在关系型数据库上解决我们现在云服务使用的搜索服务，以及 NoSQL 服务的问题。在业务场景不是特别复杂的情况下，能够让我们用最简化的技术方案去替代，降低我们产品专属化的成本。这样能够让我们的专属云产品具有良好的伸缩性，面对不同量级的客户和不同的场景，有层次的进行支撑。

有规范，以不变应万变

　　面对专属云层面的问题，结合目前各云产品的专属化问题分析，用友的技术团队，做了这方面的一些实践，打造了逐渐完善的专属云规范以及支撑服务，让基于微服务架构的云产品有据可循，交付客户从此有了套路。

　　专属云规范

　　专属云规范的目标是针对我们产品专属化中遇到的问题，提供一个标准。遵循相关的标准能够简化我们产品的专属化过程，并且在专属化过程中，提高我们产品的灵活性。

　　专属云规范分为以下几个部分：

　　·服务工程规范

　　·应用描述规范

　　·配置规范

　　·产品部署包规范

　　服务工程规范

　　服务工程规范，是 iuap-UCF 工程规范的一部分，是为了在后续研发过程中，我们能够更好的解决产品部署包的构建、预置数据脚本抽取等情况下，对我们代码开发环节做了工程结构的标准化。符合服务工程规范的应用，可以通过专属云的支撑服务，进行产品部署包的流水线构建产出，以及进行标准安装。通过规范，我们希望可以在每个服务和产品的研发阶段，就将专属化作为一部分进行考虑。

　　在服务工程规范里面，注重解决服务对产品及中间件的依赖，以及预置数据问题。对产品的依赖声明，是为了解决实际部署包的组装问题，通过依赖之间的解析，可以组装出一个可以满足需求以及可运行的部署包，根据不同的需求模块可以进行自由的组合，解决云产品融合以后，在面对实际的项目需求时，产品之间组合的问题。

　　预置数据脚本的规范，是为了解决产品部署过程中数据初始化的问题，这里不止是专属化面临的问题，我们在进行线上服务部署时，流水线构建时，都遵循相同的规范，来解决我们云服务上线时除了代码变更之外实现数据变更的识别，这样能够更自动化的去处理服务上线的变更。

有产品，交付信心爆棚

产品出盘服务能够根据专属云规范，将应用进行构建打包，产出产品的安装盘。构建服务与现有开发者中心的持续集成构建服务打通，与现有的 DevOps 流程结合，让研发能够像公有云服务产品一样，持久构建我们的产品安装盘，解决目前产品构建流程没有标准化的问题。并且提供产品及模块的管理，通过产品仓库来解决产品之间依赖问题，可以构建出具备完整依赖的产品安装盘，也减少我们由于构建安装盘投入的人力成本。将我们目前专属云产品研发的独立过程管理起来，通过出盘服务流水线记录我们的变更信息，作为我们研发流程的一环，通过工具进行管理。

　　通过产品出盘服务，也能够从研发整体上对产品的物理形态进行管理。呈现出一个产品服务的全局视图，可以让产品安装盘的构建，与我们的研发流程打通，并串联起来。后续的产品升级、补丁管理等等，都可以基于统一的视图进行管理，进行研发资产的沉淀。

　　统一安装器

　　结合我们的专属云规范，为了提高专属云部署实施的效率，我们推出了专属云安装器。作为技术中台的轻量化版本，将我们云端基础的运维服务功能进行简化。在一些规模不大的项目中，可以做到快速的实施和简单的维护。安装器提供了基础的运行环境（中间件环境、应用运行时），并且可以进行配置的动态配置，预置数据等标准的流程。与部署包构建服务无缝结合，可以直接完成我们构建部署包的安装部署。下一步，安装器将打通容器云环境与普通运行环境之间的隔离，让应用能够基于同一套标准规范，在不同的环境之间进行运行与升级。

　　采用了微服务架构的云服务，可以通过容器很好的解决分布式部署的问题，而通过技术中台统一的安装器，可以将所有的服务打包带走。那些困扰研发和实施团队的交付问题，在这种模式下都可以很好的解决，从此对基于微服务架构的云产品交付，大声说出我爱你。