【摘要】 本文介绍了基于开源自建和适配云厂商开发框架两种构建多云架构的思路，以及这些思路的优缺点。 微服务生态
微服务生态本质上是一种微服务架构模式的实现，包括微服务开发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 的场景，可以通过在不同的云上部署开源服务，来实现一套系统，多个云上运行。 云厂商如果存在微服务基础设施的商业版本， 可以在云上购买使用， 使用云产商提供的基础设施服务，通常可以降低自己运维的成本，并能够得到更好的性能优化和可靠性支持。