多云架构落地设计

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

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

开发框架选择和架构设计  

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

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

（编辑：广元站长网）

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