【摘要】 本文介绍了基于开源自建和适配云厂商开发框架两种构建多云架构的思路，以及这些思路的优缺点。
微服务生态
微服务生态实质上是一种微服务架构模式的实现，包含微服务开发 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 等性能）也都是须要的。
点击关注，第一工夫理解华为云陈腐技术~