自由轮商务系统中微服务流程的经验分享

从2016年下半年开始，Free Wheeler开始逐步将其业务系统从Rails单一应用程序迁移到微服务，同时技术堆栈从Rails迁移到Golang。两年后，整个迁移接近完成，Free Wheeler业务系统技术团队分享了他们在微服务过程中的经验。

free Wheel是一家为客户提供数字视频广告管理技术和服务的公司。它的业务侧产品需要与客户互动，并为视频广告提供一个优化的界面，类似于Web ERP。业务系统是使用Rails技术堆栈开发的，其架构是典型的三层架构。

经过近十年的研发和迭代，这个系统已经达到了几十万行代码。业务的特殊性和代码的复杂性使得团队越来越难以维护和开发新的功能:

广告系统本身的业务逻辑非常复杂，这反映在它的许多数据实体、漫长的业务流程和许多分支逻辑中。这导致代码修改困难，这可能会影响其他几个模块，也使得维护变得困难。后世不知道模块的具体实现细节，很难接管开发。

ruby本身是一种高度动态的语言，通过解释来执行。缺点是团队庞大，维护成本非常高。当发现代码时，通过查看代码很难知道问题在哪里，而且它也缺少静态检查工具，这使得代码质量难以控制。

出于这些原因，自由轮架构小组决定通过模块化来拆分系统，并整理和简化业务逻辑。当时，许多公司已经采用了微服服务，并取得了良好的效果。经过调查，架构小组决定采用微服务架构。与此同时，团队还决定切换技术堆栈，选择更有利于开发和维护的语言和工具。出于各种原因，该团队最终选择了戈兰。

在实现微服务时，许多团队选择了Java技术堆栈，毕竟，有更成熟的框架，如Spring Cloud，可以使用。自由惠勒选择戈兰的原因如下:

golang本身的访问门槛很低，并且有一个很好的标准库，可以快速开发和应用。与此同时，戈兰的生态逐渐变得丰富，许多大型项目都采用了这种生态。

在微服务过程中，需要容器。free Wheeler长期以来决定使用Docker和kubernets作为集装箱技术栈，这两个栈都是由Golang开发的。无论是熟练掌握集装箱技术还是进行一些K8S扩展开发和定制，使用Golang都是很自然的。

新技术堆栈不仅被业务系统团队使用，也被公司在开发新业务时使用。在Free Wheel之前，每个系统的技术堆栈都不同，有c++、Java和Ruby，所以从每个人都能接受的角度来看，Golang也是一个更好的选择。

该公司在美国的技术团队已经利用了Golang的经验，并在内部分享了这些经验。这样，团队可以快速理解这种新语言的特点，也可以在遇到问题时向公司内部咨询。

值得一提的是，Free Wheeler的新Golang应用是由原Rails工程师开发的。为了让这些工程师顺利进入新的技术堆栈，公司帮助团队成员通过内部共享、黑客攻击等方式快速起步，从而在短时间内形成战斗力。

当自由轮业务系统决定重组时，新的需求仍在不断产生，不可能停止需求并开发新的系统。与此同时，该团队的人力有限，无法腾出一些人来改造微服务研发。因此，该团队在开发原始Rails应用程序的同时，正在进行新的系统研究和开发。

至于设计服务的粒度，因为Free Wheeler业务系统本身已经有了成熟的数据模型，这个数据模型可以反映业务运营的概念，也可以作为每个人的通用语言。围绕这些数据模型的是业务实体，团队在确认了三四个核心业务实体后，围绕这些实体创建了大约三四个服务，最终创建的服务大约是10个，因此服务的粒度实际上相对粗糙。free Wheeler采用了微服务体系结构模型。事实上，它主要吸收了微服务架构中服务治理的一些实践经验，并从初始服务设计中的粗粒度开始。

在微服务转换过程中，团队还面临着一个相对较大的问题，即原始架构使用一个包含数千个表和许多数据分支的数据库，这使得很难拆分。为了解决数据访问问题，专门设计了一个数据访问层，通过数据访问层连接原始系统和新系统的数据库。数据访问层(内部DAL )的设计目标包括:

全局路由、控制和优化对业务数据的访问，例如从不同客户软隔离数据、读写分离等。

在没有库的情况下，通过不同的服务实现数据的划分；

将应用程序与数据库隔离，为将来拆分数据库和应用各种数据源做好准备。

其基本结构如下图所示:

最后，free wheel还需要解决在线问题，因为对于大型b类客户，它需要确保新旧系统之间的平稳切换。在这方面，对于open API，free wheel保证相同的接口和输入，通过添加一层适配器将实现切换到新的服务，并通过完善的离线测试和QA以及在线灰度分布来解决问题。此外，代码单次测试覆盖率达到80 %以上，保证了代码质量，并通过离线流量回放保证了原系统业务逻辑的顺利完成。

因为free wheel business system只有一个功能，服务之间的复杂交互很少，团队规模也很小，所以它更多地依赖kubernets提供的本地功能以及在此基础上开发的扩展来满足需求。

新的微服务体系结构如下:

具体部件的技术选择如下:

API网关包括认证、权限管理、电流限制、度量和其他功能。这部分是自我研究。最初开发它是为了将free wheel的自定义令牌身份验证切换到auth 0。最初，开发它是为了满足需求，并逐渐扩展其他功能。其请求处理流程如下:

服务框架也是由最初的自由轮Rails团队开发的轻量级框架，即内部代码轮。该框架基于Rails脚手架的概念，并根据需要扩展到GPRC，例如区分原始缓冲对象中的空值和未指定的值，以及集成现有服务，如数据访问、监控、消息传递和服务发现。与此同时，它为Docker和kubernets提供了一组单元测试、集成测试和构建工具，使业务开发团队能够快速开发满足公司代码质量和服务治理标准的服务，但只关注业务逻辑。下图显示了车轮框架中包含的主要组件:

本节中使用的K8S本地DNS组件Kube - DNS不需要额外的配置或开源工具，因为服务框架是统一的。

free Wheeler的配置中心组件基于K8S进行了扩展。目前，业界知名的配置中心开源组件拥有带Ctrip的Apollo，但配置中心实际上是K8S的核心功能，其他开源库是基于其API打包的。与其他配置中心相比，自行开发的配置中心更容易控制，也更容易发现问题。配置中心不需要面向业务，而是由研发和DEVO PS运营，因此不需要打包太多。

这将Kafka用于服务之间的数据交换。卡夫卡也是大数据平台等其他自由轮业务的重要基础设施。

新的微服务体系结构包含多个日志，包括K8S自己的日志、服务框架生成的日志、业务中隐藏点生成的日志等。团队不仅依赖日志进行监控和警告，还依赖日志进行调试。日志收集和处理系统是麋鹿。

对于Prometheus，1.0版在一段时间前发布，也是目前主流的微服务监控框架。

使用ISTIO，网络治理是微服务的关键环节，服务网格可以让开发人员摆脱琐碎的顾虑。自由轮团队主要在服务网格中使用断开连接、连接管理、流量接管、自动重试、全链路跟踪、安全性等功能。

free Wheel的业务系统重构实践可以说是中小型团队的典型微服务转型案例。它的经验值得其他团队学习，从中我们可以总结出一些成功的经验:

首先，选择合适的技术堆栈可以事半功倍，并且可以在学习新技术堆栈的同时提高团队的整体实力。

第二，对于一些具有单一功能的商业系统，如果Kuberetes被正确使用，微服务将会成功一半。团队中一定有熟悉库比列特斯并能处理各种问题的人。

第三，微服务架构通常与维持和平和研发密不可分，需要研发团队转变为Devo PS，并设计和实施新的运营和维护系统。

第四，从他们自己的需求出发，简单和核心的需求可以自我研究，而更复杂的需求可以是开源库，平衡研发能力和效率。

张寒现在是Free Wheeler的首席架构师，全面负责核心业务系统的开发，目前专注于业务系统的微服务转型。

罗欣，现任自由惠勒公司的首席工程师，目前负责公司微服框架的开发。

杨御-钱，现在是Free Wheeler的高级工程师，主要从事集装箱化的开发和推广。