构建Serverless风格的微服务架构案例

一、一次微服务架构的奇遇

2016年12月初，当时我正在以一名 DevOps 咨询师的身份参与某客户的 DevOps 转型项目。这个项目是提升该部门在 AWS (Amazon Web Services)云计算平台上的 DevOps 能力。

自助服务的应用系统基于 Ruby on Rails 框架开发，前端部分采用 AngularJS 1.0，但是没有采用前后端分离的设计，页面代码仍然是通过 ERB 组合而成。移动端则采用 Cordova 开发。为了降低开发难度和工作量， 移动端的应用内容实际上是把 AngularJS 所生成的 Web 页面通过响应式样式的方式嵌入到移动端。但因为经常超时，所以这款 APP 体验并不好。

整套 Rails 应用部署在 AWS 上，并且通过网关和内部业务系统隔离。BOSS 系统采用 SOAP 对外暴露服务，并由另外一个部门负责。因此，云上的应用所做的业务是给用户展现一个使用友好的界面，并通过数据的转化和内部 BOSS 系统进行交互。系统架构如下图所示：

应用的交互流程如下

浏览器或者移动端通过域名(由 AWS Route 53托管)转向 CDN(采用 AWS Cloudfront)。

CDN 根据请求的内容类别进行区分，静态文件(图片，JS，CSS 样式等)，会转向 AWS S3 存储。动态请求会直接发给负载均衡器 (AWS Elastic Load Balancer)。

负载均衡器会根据各 EC2 计算实例的负载状态将请求转发到不同的实例上的 Ruby On Rails 应用上。每一个应用都是一个典型的 MVC Web 应用。

EC2 上的应用会将一部分数据存储在关系型数据服务(AWS RDS，Relational Database Service)上，一部分存储在本地文件里。经过应用的处理，转换成 SOAP 请求通过 网关发送给 BOSS 系统处理。BOSS 系统处理完成后会返回对应的消息。

根据业务的需要，一部分数据会采用 AWS ElastiCache 的 Redis 服务作为缓存以优化业务响应速度。

二、团队痛点

这个应用经历了多年的开发，前后已经更换过很多技术人员。但是没有人对这个应用代码库有完整的的认识。因此，我们对整个团队和产品进行了一次痛点总结：

1. 组织结构方面

运维团队成为瓶颈，60 个人左右的开发团队只有 4 名 Ops 支持。运维团队除了日常的事务以外，还要给开发团队提供各种支持。很多资源的使用权限被限制在这个团队里，就导致各种问题的解决进度进一步拖延。

随着业务的增长，需要基础设施代码库提供各种各样的能力。然而 Ops 团队的任何更改都会导致所有的开发团队停下手头的进度去修复更新所带来的各种问题。

2. 应用架构方面

应用架构并没有达到前后端分离的效果，仍然需要同一个工程师编写前后端代码。这样的技术栈对于对于开发人员的要求很高，然而市场上缺乏合适的 RoR 工程师，导致维护成本进一步上升。经过了三个月，仍然很难招聘到合适的工程师。

多个团队在一个代码库上工作，新旧功能之间存在各种依赖点。加上 Ruby 的语言特性，使得代码中存在很多隐含的依赖点和类/方法覆盖，导致了开发进度缓慢。我们一共有 4 个团队在一个代码库上工作，3个团队在开发新的功能。1 个团队需要修复 Bug 和清理技术债，这一切都要同时进行。

3. 技术债方面

代码库中有大量的重复 Cucumber 自动化测试，但是缺乏正确的并行测试策略，导致自动化测试会随机失败，持续集成服务器 (Jenkins)的 slave 节点本地难以创建，导致失败原因更加难以查找。如果走运的话，从提交代码到新的版本发布至少需要 45 分钟。如果不走运的话，两三天都无法完成一次成功的构建，真是依靠人品构建。

基础设施即代码(Infrastructure as Code)建立在一个混合的遗留的 Ruby 代码库上。这个代码库用来封装一些类似于 Packer 和 AWS CLI 这样的命令行工具，包含一些 CloudFormation 的转化能力。由于缺乏长期的规划和编码规范，加之人员变动十分频繁，使得代码库难以维护。

此外，基础设施代码库作为一个 gem 和应用程序代码库耦合在一起，运维团队有唯一的维护权限。因此很多基础设施上的问题开发团队无法解决，也不愿解决。

我参与过很多 Ruby 技术栈遗留系统的维护。在经历了这些 Ruby 项目之后，我发现 Ruby 是一个开发起来很爽但是维护起来很痛苦的技术栈。大部分的维护更改是由于 Ruby 的版本 和 Gem 的版本更新导致的。此外，由于 Ruby 比较灵活，人们都有自己的想法和使用习惯，因此代码库很难维护。