【摘要】 本文介绍了基于开源自建和适配云厂商开发框架两种构建多云架构的思路，以及这些思路的优缺点。
微服务生态
微服务生态本质上是一种微服务架构模式的实现，包括微服务开发SDK，以及微服务基础设施。
目前比较成熟的 JAVA 微服务生态包括 servicecomb（华为）, spring-cloud (Pivotal), dubbo（阿里）, tsf（腾讯）等。gRPC、Thrift 等也用于内部服务之间的通信，但是微服务基础设施比较欠缺。
核心的微服务基础设施包括：注册中心、配置中心、应用网关。此外，分布式事物管理、计划任务、调用链跟踪系统等也是微服务基础设施的组成部分。完整的微服务基础实施还包括开发使能工具，包括接口管理工具、灰度发布管理、代码生成等，这部分主要由云厂商提供，比较少开源方案。
微服务生态的核心是 SDK，而 SDK 的核心是 RPC 框架，这个是不同微服务生态的本质区别。在基础设施方面，不同的微服务生态是可以相互选择的，比如 spring-cloud 生态可以采用 spring-cloud-huawei 接入servicecomb 提供的注册中心 servicecomb-service-center、配置中心 servicecomb-kie，也可以通过 spring-cloud-alibaba 接入阿里的配置中心；servicecomb 也可以通过引入扩展，使用其他的配置中心。一些基础的开发组件，比如 spring、spring boot，这些微服务开发 SDK 都支持集成。
对微服务生态进行比较是一个很难的课题。下面的表格仅对一些核心功能进行比较。使能工具、核心基础设施、可选基础设施等方面，不同的微服务生态是可以相互使用的，这里的比较只针对该生态原生提供的来说，并不代表某个微服务生态缺少这块功能，该生态的开发者用不了这方面的能力。对于开源生态应该采用一个大生态的眼光来看待，每个生态的设计者也会尽可能融入其他生态，继承和复用其他生态的能力。但是在商业选型上，需要考虑技术支持等因素。
对微服务生态的比较的另外一个视角就是如何构建微服务应用架构。 一般的微服务应用架构会包括应用网关、业务微服务和静态页面。静态页面的部署相对比较灵活，可以放到应用网关内部，也可以放到应用网关，还可以放到应用网关外面。其中放到网关里面的方式最灵活，比如可以通过配置网关的负载均衡策略，将请求转发到用户最近的region，也可以对部分静态页面进行访问控制。
增加应用网关可以增强应用系统的弹性，能够支撑系统的持续演进（参考分析文章），同时可以结合网络基础设施，更好的实现应用系统的能力开放。比如如果接入层使用 API Gateway 挂载，可以很好的实现内部系统的能力开放和计费；使用LVS接入，只可以提高转发性能，比较适合访问量大的应用，接入网关逻辑少，应用网关可以弹性扩容；使用DNS则对于网站很有用，屏蔽用户访问的地址差异，并且可以使用DNS将请求转发到不同区域的应用网关。
Servicecomb, spring-cloud 都能够很好的支持这种架构，而 dubbo 对这种架构支持的不是很好，很多 dubbo 开发者都是通过在业务服务之外增加一个接入层，使用 spring-cloud 的应用网关来搭建这个应用架构。
多云微服务架构的两种方案
采用开源微服务框架
很多业务系统的构建，都是从选择一个开源方案开始。 一般会首先选择一个微服务开发 SDK， 然后选择其他的微服务基础设施。 对于自主研发的情况，微服务基础设施也会选择开源方案。 比如选择 ServiceComb 微服务开发 SDK 的场景，可以通过在不同的云上部署开源服务，来实现一套系统，多个云上运行。 云厂商如果存在微服务基础设施的商业版本， 可以在云上购买使用， 使用云产商提供的基础设施服务，通常可以降低自己运维的成本，并能够得到更好的性能优化和可靠性支持。
另外一个开源解决方案是部分集成云产商提供的组件，尽可能多的使用云产商的基础设施。 比如选择 Spring Cloud 微服务解决方案， 可以使用 spring-cloud-huawei, spring-cloud-alibaba 等云产商提供的扩展，使用云上的基础设施。
下面对开源解决方案的评估点做一个总结：
1. 只需要维护一套代码和熟悉一个开发框架，多云运行。不同云的运行体验存在差异，可以部分使用云厂商的中间件。 如果其他云没有对应的中间件，需要自行安装和维护中间件。
2. 微服务框架选型之前，需要考虑“基础设施”是否也开源。比如微服务基础设施最重要的中间件“配置中心”、“注册中心”和“应用网关”。开源可获得性是一套代码，多云运行的前提。
适配多供应商开发框架
每个云产商都存在一个主打的微服务开发框架， 使用主打微服务开发框架能够最好使用云产商提供的微服务基础设施。 为了在不同的云上， 获得最佳的微服务管理能力，需要尽可能使用对应云的主打框架。 但是维护多套代码是困难的。 适配多供应商的开发框架， 需要对核心业务做好分离，避免重复开发，然后将适配层做薄，只实现简单适配，降低开发难度。 大部分 JAVA 微服务开发框架都支持 Spring， 因此可以采用下面的设计模式，实现一套核心代码，编译成多个云产商开发框架的可执行程序的多云版本。
上图是一个微服务的内部结构，一个微服务可能包含如下几个目录：
* application-core
* application-runtime-servicecomb
* application-runtime-hsf
下面对适配多供应商开发框架方案的评估点做一个总结：
1. 需要做好业务抽象，并熟悉多个开源微服务开发框架，相对于开源自建方案维护成本高。
2. 不需要考虑自行安装和维护基础中间件的问题，云厂商自己的微服务框架，一般针对这个框架提供了各种中间件支持，使用和接入开发成本低。
3. 这种方案是优秀代码架构设计。在开源方案中，也建议做好核心业务逻辑分离和接口抽象，每个方案适配不同云厂商非微服务基础设施（比如数据库、对象存储、EI等功能）也都是需要的。