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

这个过程的工作量需要通过原来代码本身的复杂度、api 接口的规范性、代码规模等进行评估。如果原来代码结构复杂，api 定义不规范，工作量会显著增加。对于良好组织的代码，这个过程则会非常容易。实际改造的一些项目，有些一天时间即可完成，有些则花费了一、两个月时间。获取到产品的业务结构、代码规模和通过简单的识别现有代码的技术栈和开发方式，能够帮助有效的评估工作量。

遗留系统改造的核心工作在于 microservice-api 中接口定义的梳理。由于 HSF 不是一个跨语言的开发框架，因此在接口定义里面使用的数据结构 ServiceComb 可能存在不支持的情况。采用一个支持跨语言的框架的接口定义作为基准（一般的，可以将接口定义通过 IDL、WSDL 或者 Open API 描述的接口定义，比如 gRPC、WebService、ServiceComb，），其他框架都实现这个接口，是微服务架构适配的核心关键。

数据库适配  

业务系统都会使用数据库。各个云厂商支持的数据库形式多样，有 MySQL、Postgre、Oracle 等，此外还有分布式数据库，以及分库分表等特性，数据仓库支持等。虽然在连接池管理、事务管理、ORM 框架等方面有大量的开源开发框架，比如 dbcp、spring transaction、MyBatis 等，它们仍然没法覆盖所有的应用场景。适配多云架构对于业务代码开发有如下建议:

尽可能使用符合 ANSI SQL Standard 的 SQL 语句。比如 MySQL 在大小写、Column 引用、Limit、Group by 语句等方面都有自己的特殊用法。为了更好的适配多云数据库，应该避免使用特殊用法，除非对于业务价值具备明显的价值，而且没有对等的解决方案。

选用一个被广泛采用的 ORM 框架。比如 MyBatis、JPA 等。这些框架被广泛支持，对于多数据库支持得到比较充分的验证。在使用数据库有差异的地方，提供了非常良好的扩展机制。比如使用 MyBatis，可以使用 DatabaseProvider 接口，来屏蔽语法差异。在使用 JDBC 或者 JDBCTempate 拼接 URL 的地方，则可以通过接口的不同实现，返回不同的 SQL 语句。

<if   test="_databaseId == 'mysql' "> 
limit   #{stratRow},#{rowCount} 
</if> 
<if   test="_databaseId == 'postgresql' "> 
limit   #{rowCount} offset #{stratRow} 
</if> 

分布式数据库、分库分表、分析型数据库对于业务开发存在不同的限制。比如对于唯一索引使用的限制、对于分库分表键的修改限制等。对于这些场景，尽可能符合这些限制，调整业务实现方式，避免为了满足某个不重要的场景需要，陷入一些分布式场景无法解决的问题当中去，而无法适配其他云厂商的数据库。

缓存适配  

各个厂商均支持 Redis 作为缓存，但是在 Redis 发展路径上，有不同的分支。一个分支是 Proxy 集群模式，一个分支是 Redis 的原生集群方式。Redis 提供的客户端 API 也存在两套，一个是 Jedis，一个是 JedisCluster，两套支持的命令集合不尽相同。比如 Proxy 集群模式能够非常好的支持所有的 Jedis 命令，而 Redis 的原生集群方式只支持 JedisCluster 命令。很多客户常用的 pipeline 指令，在 Redis 原生集群方式下不支持。

Proxy 集群能够更好的屏蔽底层服务的差异，在没有特殊需要的情况下，建议用户使用 Proxy 集群模式，云厂商需要通过 Proxy 集群模式提供对于 Jedis 不同指令的支持。用户也可以选择 Redis 的原生集群，这个在不同的云产生也都提供了支持，用户可以在业务场景上避免使用原生集群不支持的命令，这样就可以在多云环境上部署。

总结起来，缓存的多云支持的最佳实践：及时升级 Client API 版本，使用比较新的 Client API，并且只使用 JedisCluster 提供的指令集合。

消息中间件适配  

相对于数据库和缓存，消息中间件的适配的标准性更弱一点。虽然早期 JAVA 提出了 JMS 等标准，但是目前主流的消息中间件都没有提供 JMS 接口的实现。阿里的 RocketMQ、华为基于 Kafka 的 DMS 的接口均不一致。而且消息中间件的服务质量并不一样，比如在消息有序投递、重复投递等方面是通过消息中间件配置提供的，而不受客户端接口控制。有些客户的业务逻辑依赖于特定消息中间件的机制，因此需要对消息中间件使用的接口、接口行为进行抽象，分析其他云厂商的中间件能否提供对应的接口实现并满足对应的服务质量要求，有时候需要业务代码做一些补偿，以弥补不同中间件服务质量的差异。

其他中间件适配  

其他中间件包括日志服务器、定时任务服务、对象存储服务等等。适配的总体思路一致，这里不详细描述里面的细节。

多云架构的挑战和建议  

和做协议标准一样，多云架构除了给客户带来商业上的灵活性，还会促进业务系统软件架构的改善，提升整体的软件质量。因为多云架构需要对使用的技术点进行权衡，技术选型上更多采用相对中立和标准的方案，这些方案被广泛验证，相对于使用一些私有特性来说，更加稳定，同时可以促进项目开发人员之间的技术交流和能力继承。在给客户做多云架构落地的实践中，通过架构交流，帮助客户梳理了整体的架构演进方向，还发现了很多历史问题，对于客户的代码质量提升起到了很大作用。

多云架构也面临特别多的挑战。首先是短期内企业维护成本的增加和技术成本的增加，需要投入专家解决前期的架构适配问题，为系统持续演进搭好框架。多云系统运行，还会增加业务数据同步，不同云上系统如何进行协同的问题。只有当客户多云系统相对独立，没有数据共享和业务交互的场景才比较简单。多云系统还会影响到客户的交付效率，不同云的持续交付方式存在较大的差异，运维人员的体验不同，会降低日常的效率。

因此，多云架构更多的是准备“备胎”，客户的主要业务还是以单一云厂商提供。多云架构给客户对比不同云厂商的服务质量提供了非常准确的参考，客户能够更加准确的选择优质的供应商。

（编辑：核心网）

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