多云架构落地设计和实施方案

1、多云架构落地设计和实施方案“不要把鸡蛋放在同一个篮子里”是一条知名的商业准则，在云平台 选择上，很多公司也遵循这样的准则。基于多云平台构筑“业务中 台”并不是一件简单的事情，需要构建一种快速继承、可持续迭代的 路径，帮助整体方案落地。本文以实际项目案例为例，分析项目的架 构设计、实施步骤，以及多云架构面临的挑战和机遇。总体思路6不同云厂商提供的云服务不尽相同，相同的云服务在功能、性能上也会有或多 或少的差异。越是深度使用某个云厂商的云服务，越是难于迁移到其他云厂商。 选择自己构建云服务，则技术门槛.维护成本很高确定多云架构以后，首先 需要在技术栈的选型上做好折中。一个基本的原则是通过业务架构的

2、灵活性, 去适配不同的云厂商，尽可能的使用云厂商提供的优秀特性，提升运行于该云 平台的业务系统的可靠性，提升整体业务的竞争力。上面的思路和一些客户常见的思路有显著差别。有些客户选择采用开源软件, 搭建自己的PaaS平台；有些客户则完全采用云厂商的技术栈，开发两套业务 系统。这两种方式是两个极端，前者开发和运维难度高，往往由于技术风险评 估不足，项目无法如期交付，或者产品竞争力太弱，没有云厂商提供的服务好 后者则需要维护两套系统，代码重复度高，还会被云厂商完全绑定，失去谈判 的筹码，业务发展灵活性降低。还有些客户捉望云厂商提供足够兼容性的框架 支持，在不改造现有业务系统的逻辑的情况下实现多云部署

3、，云厂商这方面的 努力通常由于客户系统的复杂性和多样性得不到落地。开发框架选择和架构设计6开发框架设计是多云架构的核心，也是抽象程度最高的部分。华为云主推 ServiceComb作为微服务框架，阿里云主推HSF、Dubbo作为微服务框架， 其他国外的云厂商，多数选择Spring Cloud作为微服务框架，另外还有其他 不同的语言和框架选择。虽然mesher等技术为多语言协同工作提供了良好的 支持，但是为了最大限度的利用框架特性，帮助快速构建稳定可靠的业务系统， 选择一个微服务开发框架仍然是必不可少的.基于总体思路，多云架构期望在华为云上使用ServiceComb运行时，在阿里 云上使用HSF运

4、行时，并且支持Spring Cloud运行时。完成这个目标，首先 需要对微服务运行框架的运行时和主要组成部分有所了解。对于多数中台系统, 对于框架运行时的依赖，一般都是RPC框架以及基于RPC框架做的服务治 理能力，包括服务注册发现、熔断容错、限流等机制.将业务逻辑核心代码， 与微服务框架能力进行解耦，是设计的第一步。上面的图形展现了基本的逻辑架构。 业务核心：技术选型上使用Spring、Spring Boot. ServiceComb. HSF和 Spring Cloud等微服务框架的技术底座，都可以基于Spring, Spring Boot 技术栈来构建.在逻辑架构下，需要将微服务代码进行

5、分层，包含下面三个主要目录： microservice-api:定义微服务的接口.该目录包含接口定义（interface）、数据结构圧义（models）。为了支持不同的微服务框架，对 于按口定义和数据结构定义会冇一定的耍求。 microservice-service:业务逻供实现代码。 microserviceendpointservicecomb: 发布为 ServiceComb 的微服务项 目。 microservice-endpoint-hsf:发布为 HSF 的微服务项口。 microservice-endpoint-springcloud:发布为 Spring Cloud 的微服务项

6、 目。这个代码分层实施的核心关键是api设计，以及业务逻辑实现和服务发布解耦. api设计需要满足不同的微服务框架的设计要求。这里涉及到RPC编解码的基 础。RPC编解码通常分为语言无关（跨平台）和语言相关（不跨平台）。比如 HSF、Dubbo的缺省编解码是语言有关的，只能够支持JAVA程序之间的通 信，ServiceComb缺省采用Jackson编解码，或者protobuffer编解码，这 两种方式都基于Open API 2.0进行走义，可以做到语言无关，Spring Cloud 则相对复杂一些，它是一种混合型的编码格式，可以通过灵活的序列化定制, 满足多样性需要，也可以严格遵循Jackso

7、n和OpenAPI标准。通常语言无关 的编解码可以完全包含语言无关的编解码要求，因此api走义的时候，需要做 到语言无关，才能够保证api能够在不同的微服务开发框架下得到最好的实现. 基于本文是描述工程实践，不详细探讨关于跨平台设计的原理，下面列出一些 接口设计的准则：使用简单的类型（比如Integer, String, Boolean等）定义参数或者返回值。 或苕便用包含简单类型的，符合Java Bean规范的POJO Bean定义参数或 者返回值。尽可能不使用interface, abstract class,存在多个实现的基类,模板类作为参 数或者返回值。不便用运行环境强相关的对象作为接

8、口参数或者返回值。比如 HttpServletRequest RpcContext Invocati onCo ntext Res on seE ntity 等。上面的原则从使用者的视角来看，是非常容易理解的。接口语义清晰，没有 歧义，直接通过接口定义就能够理解接口的参数个数以及如何传递，不需要 提供额外的文档或者查看源代码。有利于通过接口定义生成文档、swagger 定义。在实际项目中，开发者需要理解microservice-api是微服务之间的接口定 义，接口设计需要考虑数据的序列化和反序列化.这个不同于内部接口设 计。为了降低业务实现逻辑的重复度，增强内聚性，内部接口设计会更多的 使用抽

9、象、继承进行逻辑封装.内部接口的数据结构，还会包含一些额外的控制逻辑。比如数据库访问层的数据结构，提供懒加载等机制，当访问到getter方法的时候，实际上调用的是代理对象的getter方法.因此，需要有 一些数据结构转换逻辑，将内部的数据结构转换为外部接口的数据结构，以保持服务之间接口和内部接口的界限清晰，防止将内部数据结构作为参数或者返回值，导致内部信息泄露，造成不可预期的处理结果。api示例interface LoginService SessionInfo login(String username String password);public class Sessioninfo pr

10、ivate String sessionld; private String username;service 示例ServicePrimarypublic class LoginServicelmpl implements Loginservice public SessionInfo login(String username， String password) / do LoginServiceComb Endpoint 示例服务端：Rp(S f e ia(schemald = LoginServiceEndpoint)public classLoginServiceEndpoint i

11、mplements LoginService Autowired privateLoginService service;public SessionInfo login(String username. String password)厂eturnservice.login(username， password); 客户端:Beanpublic LoginService getLoginService() return Invoker.createProxy(SERVICE_NAMEJ LoginServiceEndpoint LoginService.class);或者RpcReferen

12、ce(microserviceName=SERVICE_NAME, schemaId=JLoginServiceEndpoint)private LoginService loginService;HSF Endpoint 示例服务端：(serviceinterface = LoginService.classserviceversion 1.0.0)public class LoginServiceEndpoint implements LoginService Autowired private LoginService service;public SessionInfologin(St

13、ring username， String password)“eturnservice.login(username， password); 客户端:HSFConsumerprivate LoginService loginService;从上面的代码示例看，Endpoint层需要做到尽可能逻辑简单，实现逻辑全部交给Service层，只包含接口声明，或者包含必要的数据结构转换逻辑。上面 的方式演示了 RPC的接口声明，还可以加上REST标签(Spring MVC,或者 JAX RS),来支持 REST 接口.遗留系统的改造策略大部分公司都会存在现有系统运行于某一个云上，把现有系统推倒重来，逬

14、行 全新设计，通常不是一个好主意。遗留系统的改造需要遵循持续迭代，继承性 改造的思路。以阿里云系统改造为华为云系统为例，将原来基于HSF开发的微服务应用改 造为基于ServcieComb开发的微服务应用。按照前面的总体思路，首先需耍将原來项口强依赖HSF的代码部分分离岀 來.建立下面的日录结构：microservice-api:圧义微服务的按口。该I录包含按I定义(interface)、 数据结构進义(models)。为了支持不同的微服务框架对丁接口止义和数据结构定义会有一定的耍求。microservice-service:业务逻侏实现代码。 microservice-endpoint-hsf

15、:发布为 HSF 的做服务项口。这个过稈相对而言是简单的，不涉及仟何IV务逻辑的调勢，只是代码冃录结构的变化和POM依赖关系的调整。调整完成后，可以对现有功能逬行简单自动 化验证，保证项目自动化测试用例能够通过.调整后的项目功能和遗留系统是 一致的，拥有一个始终无损的运行系统，对于功能比较、问题发现都是非常有 帮助的。项目调整后，就可以増加华为云的项目：microservice-endpoint-servicecomb: 发布为 ServiceComb 的微服务项目。这个项目可以复制 microservice-endpoint-hsf ,将 POM 依赖改为 ServiceComb的内容，并将

16、发布的接口 (Endpoint)调整为ServiceComb的 发布方式。项目调整后，就可以一份代码构建出两个可执行jar包，两个jar包分别在华 为云和阿里云部署。这个过程的工作量需要通过原来代码本身的复杂度、api接口的规范性、代码 规模等进行评估。如果原来代码结构复杂，api走义不规范，工作量会显著増 加。对于良好组织的代码，这个过程则会非常容易。实际改造的一些项目，有 些一天时间即可完成，有些则花费了一、两个月时间。获取到产品的业务结构、 代码规模和通过简单的识别现有代码的技术栈和开发方式，能够帮助有效的评 估工作量。遗留系统改造的核心工作在于microservice-api中接走义的

17、梳理.由于 HSF不是一个跨语言的开发框架，因此在接口定义里面使用的数据结构ServiceComb可能存在不支持的情况。采用一个支持跨语言的框架的接口定 义作为基准（一般的，可以将接口走义通过IDL、WSDL或者Open API描 述的接口定义，比如gRPC、WebService. ServiceComb,）,其他框架都 实现这个接口，是微服务架构适配的核心关键。数据库适配6业务系统都会使用数据库。各个云厂商支持的数据库形式多样，有MySQL、 Postgre. Oracle等，此外还有分布式数据库，以及分库分表等特性，数据仓 库支持等。虽然在连接池管理、事务管理、ORM框架等方面有大量的开源

18、开 发框架，比如dbcp、spring transaction. MyBatis等，它们仍然没法覆盖所 有的应用场景。适配多云架构对于业务代码开发有如下建议：1. 尽可能使用符合ANSI SQL Standard的SQL语句。比如MySQL在大小写、 Column引用、Limit、Group by语句等方面都有自己的特殊用法.为了更好 的适配多云数据库，应该避免使用特殊用法，除非对于业务价值具备明显的价 值，而且没有对等的解决方案.2. 选用一个被广泛采用的ORM框架。比如MyBatis. JPA等。这些框架被广泛 支持，对于多数据库支持得到比较充分的验证.在使用数据库有差异的地方,提供了非常

19、良好的扩展机制。比如使用MyBatis,可以使用DatabaseProvider 接口，来屏蔽语法差异。在使用JDBC或者JDBCTempate拼接URL的地方, 则可以通过接口的不同实现，返回不同的SQL语句。limit#stratRovj#rouCountlimit roMCount offset #stratRow3. 分布式数据库、分库分表、分析型数据库对于业务开发存在不同的限制。比如 对于唯一索引使用的限制、对于分库分表键的修改限制等。对于这些场棗，尽 可能符合这些限制，调整业务实现方式，避免为了满足某个不重要的场景需要， 陷入一些分布式场彊无法解决的问题当中去，而无法适配其他云厂商

20、的数据库。缓存适配各个厂商均支持Redis作为缓存，但是在Redis发展路径上，有不同的分支。 一个分支是Proxy集群模式，一个分支是Redis的原生集群方式。Redis提供 的客户端API也存在两套，一个是Jedis, 一个是JedisCluster,两套支持的 命令集合不尽相同.比如Proxy集群模式能够非常好的支持所有的Jedis命 令，而Redis的原生集群方式只支持JedisCluster命令。很多客户常用的 pipeline指令，在Redis原生集群方式下不支持.Proxy集群能够更好的屏蔽底层服务的差异，在没有特殊需要的情况下，建议 用户使用Proxy集群模式，云厂商需要通过P

21、roxy集群模式提供对于Jedis不 同指令的支持.用户也可以选择Redis的原生集群，这个在不同的云产生也都 提供了支持，用户可以在业务场景上避免使用原生集群不支持的命令，这样就 可以在多云环境上部署。总结起来，缓存的多云支持的最佳实践：1及时升级Client API版本,使用比较新的Client API,并且只使用JedisCluster 提供的指令集合。消息中间件适配6相对于数据库和缓存，消息中间件的适配的标准性更弱一点.虽然早期JAVA 提出了 JMS等标准，但是目前主流的消息中间件都没有提供JMS接口的实现。阿里的RocketMQ.华为基于Kafka的DMS的接口均不一致.而且消息中间 件的服务质量并不一样，比如在消息有序投递、重复投递等方面是通过消息中 间件配置提供的，而不受客户端接口控制。有些客户的业务逻辑依赖于特定消息中间件的机制，因此需要对消息中间件使用的接口、接口行为进行抽象，分 析其他云厂商的中间件能否提供对应的接口实现并满足对应的服务质量要求, 有时候需要业务代码做一些补偿，以弥补不同中间件服务质量的差异。其他中间件适配6其他中间件包括日志服务器、定时任务服务、对象存储服