9.2 融数数据微服务的架构选型
我们在构建微服务体系的过程中，经历了技术选型、技术验证、引入开源实现及完全自研等一系列的过程，其中也走过不少弯路，现在回想起来，感触良多，在这里跟大家分享一下，希望能够有所帮助。对于技术选型，我们不希望重复发明轮子，也不希望完全受制于开源的实现，所以在技术选型时遵循如下原则：
考察社区热度、架构成熟度、学习曲线、可维护性，如图 9.3 所示。
尽量照顾现有服务的开发方式和框架的使用习惯，不对目前的研发团队造成太大的冲击。能够给程序员提供何种能力？我们的期望是：
- 方便开发
- 方便迁移
- 多协议支持
- 多语言支持
- 方便监控
- 方便运维
我们比较了可能用到的一些开源服务框架，并对它们的功能点进行了评估，如图 9.4 所示。
由于之前团队采用 RESTEasy + Spring Boot 的方式实现服务，不希望对现有的系统和产品产生太大的影响，因此决定服务框架首先需要支持 REST 服务，又由于 Netflix 提供了比较全面的解决方案，并且 Spring Cloud 在遵循 cloud-native 原则的基础上对 Netflix 进行了比较友好的封装，因此初步的结论是可以基于 Spring Cloud 进行二次开发，封装我们自己的微服务框架。
经过半年的实践，我们发现 Netflix 技术栈的思想不错，但是很多实现并不是特别完美，例如：
Zuul 提供的 Edge Service 及 API 网关是完全基于 HTTP 协议的过滤器实现的，基于 HTTP 协议的同步调用方式会带来性能的损失，并且缺乏长连接的推送及多路复用的能力。
Zuul 不能满足 RPC 调用的需求，而在大规模团队协作的过程中，契约优先的开发方式优于代码优先的开发方式，因此对于应用内部交互来讲，RPC 框架从管理和协作的角度要优于 REST 服务。
基于 Eureka 的服务注册依然是中心化治理的方式，与传统基于 ZooKeeper 或者 etctd/consul 的治理方式一样，中心化的治理会给服务的部署带来非常大的阻碍，需要对不同的环境配置不同的中心注册服务器，服务的版本管理及服务注册信息的同步也会带来问题，更加糟糕的是，在某些服务不正常的情况下，客户端需要进行大量的判断，防止出现治理风暴等问题。
因此，我们后来果断转换思路，对之前的微服务框架进行了彻底的改造：
1、基于对 gRPC 的封装，构建 Service Provider 的全新实现，替代 REST 服务。
2、通过 Proxy 方式，实现 gRPC 与 REST 服务的相互转换，保持系统兼容性。
3、进行去中心化治理，通过 Proxy 来实现端点治理，将客户端治理变为服务端治理。
4、通过扩展并集成 Zipkin 实现服务链路监控和运行时拓扑收集。
5、构建 Endpoint inventory 服务，以 semantic versioning 的方式管理服务版本。
6、将 Proxy 作为服务部署的执行端点，通过 VIP 绑定，透明化客户端寻址工作。利用 Proxy 提供轻量级的负载均衡、流量控制及灰度发布的功能。
9.3 设计思想
融数数据微服务架构的整体设计思想如图 9.5 所示。
该设计思想的具体说明如下。
面向运维的设计，配合 DevOps 平台，提供服务生命周期管理及易于被监控的能力。
面向开发者，合理封装。开发者无须了解 gRPC 的具体实现。
基于 IDL 的契约优先的开发方式。
提供完善的测试框架和 Mock 工具。
提供完善的易于监控的能力。
