微服务技术选型

由于FreeWheel业务系统功能较为单一，服务间的复杂交互不多，团队规模也不大，因此在进行微服务改造时较多依赖Kubernetes提供的原生能力，以及在它基础上开发的扩展来满足需求。

新的微服务架构如图：

具体组件的技术选型如下：

API网关

API网关包括认证、权限管理、限流、Metrics等功能，这一部分为自研。它最初是为了将FreeWheel的自定义Token认证切换到Auth0而研发的，一开始就是为了满足需求，逐渐扩展出其它功能，其请求处理流程如下：

服务框架

服务框架也为FreeWheel原Rails团队自研的轻量级框架，内部代号Wheels，该框架借鉴了Rails脚手架的理念，基于gPRC进行了必要的扩展，比如在Protobuffer对象中区分空值和未指定等，并集成了已有的数据访问，监控，消息，服务发现等服务，同时提供了一组单元测试，集成测试和面向Docker和Kubernetes的构建工具，使业务开发团队能快速开发出一个符合公司代码质量和服务治理标准的服务，而只需关注业务逻辑本身。下图展示了Wheels框架所包含的主要组件：

服务注册发现

这部分使用的K8S原生DNS组件Kube-DNS，因为服务框架统一，所以无需进行额外配置或使用开源工具。

配置中心

FreeWheel的配置中心组件基于K8S进行扩展而来，目前业界比较知名的配置中心开源组件有携程的Apollo，但配置中心其实是K8S的一个核心功能，其它的开源库都是在它的API基础上封装而来。自研的配置中心与其它相比更有可控性，出了问题方便排查，该配置中心也无需面向业务，而由研发和DevOps负责操作，因此无需封装的太多。

数据总线

这个使用Kafka进行服务间的数据交换。Kafka也是FreeWheel其它业务如大数据平台重要的基础设施。

日志

新的微服务架构里包含多个日志，包括K8S本身的日志、服务框架产生的日志、在业务中埋点产生的日志等，团队不仅依靠日志做监控和告警，也通过日志来做Debug。对日志收集处理的系统为ELK。

监控与告警

使用Prometheus，前段时间发布了1.0版本，也是目前主流的微服务监控框架。

Service Mesh

使用Istio，网络治理对于微服务来说是非常关键的一环，而Service Mesh可以将开发人员从一些琐碎的关注点中解救出来。FreeWheel团队主要利用了Service Mesh中的断路、连接管理、流量接管、自动重试、全链路跟踪、安全等功能。