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

“不要把鸡蛋放在同一个篮子里”是一条知名的商业准则，在云平台选择上，很多公司也遵循这样的准则。基于多云平台构筑“业务中台”并不是一件简单的事情，需要构建一种快速继承、可持续迭代的路径，帮助整体方案落地。本文以实际项目案例为例，分析项目的架构设计、实施步骤，以及多云架构面临的挑战和机遇。

总体思路  

不同云厂商提供的云服务不尽相同，相同的云服务在功能、性能上也会有或多或少的差异。越是深度使用某个云厂商的云服务，越是难于迁移到其他云厂商。选择自己构建云服务，则技术门槛，维护成本很高。确定多云架构以后，首先需要在技术栈的选型上做好折中。一个基本的原则是通过业务架构的灵活性，去适配不同的云厂商，尽可能的使用云厂商提供的优秀特性，提升运行于该云平台的业务系统的可靠性，提升整体业务的竞争力。

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

开发框架选择和架构设计  

开发框架设计是多云架构的核心，也是抽象程度最高的部分。华为云主推 ServiceComb 作为微服务框架，阿里云主推 HSF、Dubbo 作为微服务框架，其他国外的云厂商，多数选择 Spring Cloud 作为微服务框架，另外还有其他不同的语言和框架选择。虽然 mesher 等技术为多语言协同工作提供了良好的支持，但是为了最大限度的利用框架特性，帮助快速构建稳定可靠的业务系统，选择一个微服务开发框架仍然是必不可少的。

基于总体思路，多云架构期望在华为云上使用 ServiceComb 运行时，在阿里云上使用 HSF 运行时，并且支持 Spring Cloud 运行时。完成这个目标，首先需要对微服务运行框架的运行时和主要组成部分有所了解。对于多数中台系统，对于框架运行时的依赖，一般都是 RPC 框架，以及基于 RPC 框架做的服务治理能力，包括服务注册发现、熔断容错、限流等机制。将业务逻辑核心代码，与微服务框架能力进行解耦，是设计的第一步。

上面的图形展现了基本的逻辑架构。

业务核心：技术选型上使用 Spring、Spring Boot。ServiceComb、HSF 和 Spring Cloud 等微服务框架的技术底座，都可以基于 Spring、 Spring Boot 技术栈来构建。

在逻辑架构下，需要将微服务代码进行分层，包含下面三个主要目录：

• microservice-api：定义微服务的接口。该目录包含接口定义（interface）、数据结构定义（models）。为了支持不同的微服务框架，对于接口定义和数据结构定义会有一定的要求。
• microservice-service：业务逻辑实现代码。
• microservice-endpoint-servicecomb：发布为 ServiceComb 的微服务项目。
• microservice-endpoint-hsf：发布为 HSF 的微服务项目。
• microservice-endpoint-springcloud：发布为 Spring Cloud 的微服务项目。

这个代码分层实施的核心关键是 api 设计，以及业务逻辑实现和服务发布解耦。api 设计需要满足不同的微服务框架的设计要求。这里涉及到 RPC 编解码的基础。RPC 编解码通常分为语言无关（跨平台）和语言相关（不跨平台）。比如 HSF、Dubbo 的缺省编解码是语言有关的，只能够支持 JAVA 程序之间的通信，ServiceComb 缺省采用 Jackson 编解码，或者 protobuffer 编解码，这两种方式都基于 Open API 2.0 进行定义，可以做到语言无关，Spring Cloud 则相对复杂一些，它是一种混合型的编码格式，可以通过灵活的序列化定制，满足多样性需要，也可以严格遵循 Jackson 和 Open API 标准。通常语言无关的编解码可以完全包含语言无关的编解码要求，因此 api 定义的时候，需要做到语言无关，才能够保证 api 能够在不同的微服务开发框架下得到最好的实现。基于本文是描述工程实践，不详细探讨关于跨平台设计的原理，下面列出一些接口设计的准则：

• 使用简单的类型（比如 Integer, String, Boolean 等）定义参数或者返回值。或者使用包含简单类型的，符合 Java Bean 规范的 POJO Bean 定义参数或者返回值。
• 尽可能不使用 interface, abstract class, 存在多个实现的基类，模板类作为参数或者返回值。
• 不使用运行环境强相关的对象作为接口参数或者返回值。比如 HttpServletRequest，RpcContext，InvocationContext，ResonseEntity 等。

上面的原则从使用者的视角来看，是非常容易理解的。接口语义清晰，没有歧义，直接通过接口定义就能够理解接口的参数个数以及如何传递，不需要提供额外的文档或者查看源代码。有利于通过接口定义生成文档、swagger 定义。

在实际项目中，开发者需要理解 microservice-api 是微服务之间的接口定义，接口设计需要考虑数据的序列化和反序列化。这个不同于内部接口设计。为了降低业务实现逻辑的重复度，增强内聚性，内部接口设计会更多的使用抽象、继承进行逻辑封装。内部接口的数据结构，还会包含一些额外的控制逻辑。比如数据库访问层的数据结构，提供懒加载等机制，当访问到 getter 方法的时候，实际上调用的是代理对象的 getter 方法。因此，需要有一些数据结构转换逻辑，将内部的数据结构转换为外部接口的数据结构，以保持服务之间接口和内部接口的界限清晰，防止将内部数据结构作为参数或者返回值，导致内部信息泄露，造成不可预期的处理结果。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!