「最佳实践」基于微服务的零运维、百万级用户平台架构实现
陈欢嘉是一名舞蹈老师，王雅渊在三里屯给别人文身，谢淮琳在北医三院每天完成三例心脏搭桥手术，每个人在生活中的角色各不相同，但在「轻课」，他们有一个相同的身份 —— 课程「班长」。轻课定位于实用兴趣英语，包含词汇、语法、口语、写作等内容，以「图片+文字+语音流」的形式展现课程，同时在微信公众号「轻课小伙伴」上每日更新，方便上班族利用碎片化的时间给自己充电，同时有相似学习目标的学员可以在微信群中「成班」，选举「班长」，同谢淮琳、王雅渊和陈欢嘉一样，课程的班长多为兼职，负责督促着同学们打卡，同时辅导同学，在教授他人的过程中强化自身学习。可是，在线英语培训机构那么多，轻课为何会获得资本青睐（获 3300 万元人民币 A 轮融资）？与普通的在线培训机构有什么区别呢？第一，轻课有基于社群模式打造的整条产品线；第二，轻课基于人工智能的方法能够有效评估学员的学习效果；第三，轻课以一种易于接受游戏化的方式和内容传播的方式，把学习变的更轻量化，这样有助于增加学员的学习热情。轻课产品线与技术栈轻课直播 APP，基于即时语音以及 PPT 的展现形式；微信订阅，基于微信传播的课程 H5 界面；轻课网校，基于轻课网校 APP 精品化内容的点播回放；智能评分，通过跟读练习的语音评测智能成果提示，以及其他一些社群运营的人工服务的方式的提示。这是轻课使用的一部分技术栈，主要的编程语言是基于 Scala 的 Twitter 生态圈的 Finatra 框架做的整套微服务的体系。Twitter Finatra 是由 ruby 的 sinatra 演变而来，因为它借鉴了 ruby sinatra 的简便性以及接口的易用性。Twitter Finatra 是面向微服务设计的一种可测的语言，因此对微服务和 devops 整体模型有很大的帮助。轻课 APP 端尝试使用 React Native 进行开发，以前端化的构思，能够用最快的时间，最简捷的技术迭代轻课产品，继而实现一些新的功能。轻课选择了能够兼容java框架，基于 Finatra 双语言实现，结合容器、结合微服务、结合 devops 模型进行部署开发，前端使用 vue.js、node.js 作为中间件。整个 IT 架构都围绕着一个原则：最小的资源做最佳的事。围绕着这一原则，轻课 CTO 黄曦在设计轻课的 IT 架构时主要从两个方向进行思考：一是要满足产品快速上线。 为此黄曦选择了响应式框架作为轻课的技术框架，可以实现在生产环境中写代码，这边编程，那边就能直接上线运行，这使得轻课的上线速度特别快。二是从一开始就采用微服务 + Docker 的技术架构。 国内关于 Docker 的争论一直存在，直到现在很多人还是认为 Docker 只能在测试环境使用，但黄曦表示自己其实已经在非常严谨的平台下使用了很久。「Qing 」课遇上 「Qing」 云轻课是如何与 QingCloud 结缘的？轻课第一个版本是基于微信的信息转发功能，后来增加了包括订单系统，业务逻辑的微服务，慢慢的轻课需要比较健全的内网 VPC 架构体系，因为所有的微服务不可能在通信，需要基于内网。轻课 CTO 黄曦了解到青云完全具备 VPC 内网隔离功能，更深入的了解之后，秒级创建、
按秒计费、弹性计费等功能更是非常符合创业中的公司。在资源有限的情况下，该弹性功能更大程度上为轻课节约成本。另外在轻课使用过程中，轻课在运维过程中产生任何问题，包括网络方案的管理，中间件的配置，以及创建数据库还有 redis 集群时，一条工单，即可解决以上所有问题。后期轻课实行数据驱动的模式，基于青云可以很轻松的创建基于 spark 的数据平台，从轻课第一个版本上线到 A 轮之前的一年半中，轻课没有专职运维人员，所有资源都由后台工程师创建调试好。轻课与微服务架构有很多种，轻课为什么选择微服务架构？首先轻课是比较年轻的团队，愿意尝试新的技术，新技术能够带来一些独到的优势，新技术又可以驱动整个团队的技术氛围。轻课虽然是一家以运营驱动的教育公司，但是轻课的技术氛围不亚于国内任何一个技术公司。这和黄曦在接触 scala 的同时也接触到了微服务理念有关。关于微服务现在业界有很多种争论，轻课在使用微服务的过程中也积累了一些经验。微服务只是一个架构理念，一个工程师新到团队，面对一个硕大的 monolith 应用，可能会花很多时间在沟通和学习上，增加了大量的学习成本，但如果你把它切成可控的微服务单元，这样就会降低学习成本，之后维护也会更方便。是否需要把轻课现有的 monolith 单体应用进行重构呢？如果有机会大家可以在新项目中尝试微服务架构，老项目在没有出现重大问题的情况下，不建议使用，因为，一成本太高；二重构之后的系统不一定就可以马上带来像之前系统那么稳定的效果。实现微服务首先选择什么框架？微服务本身是架构理念，实现有各种方法，基本上框架是大同小异。基于 REST 的风格进行接口定义，普通的 MVC 可以当成 RESTful 接口，但是不是面向这种特性实现的，用 MVC 实现，会造成一些问题，比如说你打得包过大，有一些组件在底层支持上不是那么健全，不是面向 devops 交付模式进行编辑的，可能在测试方法上，功能测试的组件上提供不如原生更好。另外新框架也有，比如说像 springcloud，但其底层的支持更新速度没有这么快，有一些问题出现以后没有办法及时更新，另外学习资料不够多，遇到的坑比资料多。这是我在国内接触的很多企业中，大家遇到的一些问题。轻课的敏捷开发轻课开发的模型使用的是敏捷模型中的 scrum，scrum 模型是轻课经过实践以后不断迭代出来的工作流程。这个模型并不是轻课一开始就采用的，轻课第一个版本上线使用的是看板模型，看板模型它是以责任制，以人员分工领任务的模式。scrum 模型通过一个迭代周期，一个流水交付的形式去做这样一个流程。迭代的时候轻课遵循最小化、可行性产品思路，通过产品提炼轻课所需要的功能，通过开发快速交付以及上线，轻课整个流程微服务+容器化+ DevOps 交付模式构建了一个架构，微服务只是轻课一个架构理念，它不会单独出现，甚至说它单独出现没有任何意义，它永远是伴随 DevOps 的交付模型，以及 docker 容器化技术的部署模型产生的。关于部署的方法。关于 CI 持续集成工具，大家用得比较多的是类似于 Jenkins 工具，Jenkins 是比较流行的工具，我经常问轻课面试者觉得 Jenkins 怎么样？他们回答说，Jenkins 仅仅是一个部署工具一个打包工具而已。对传统框架，单体架构这样理解是没有错的，但是如果是持续集成、以及
交付 DevOps 模式这样理解就会有一些问题，假如你需要打包，一个部署脚本就能够解决，为什么用那么复杂的一个系统。CI 的全称叫做管道集成，为什么叫管道集成？首先这个代码从 GIT 源推进这个版本号以后，放在主版本之后整个管道被激活，激活过程当中第一个做的工作并不是打包，而是执行单元测试，单元测试执行完之后，代表你这次改动不会影响之前编写逻辑的覆盖。第二步在单元测试过后轻课再放到集成测试环境，以组件形式验收你这次更改会不会对其它组件造成影响，如果没有造成影响。第三步轻课会把其方在点对点或者叫功能测试的环境中，以真实接口请求的形式模拟当前的输出，检验这个接口形式有没有覆盖预期。从点对点环境中移到压力测试环境中，如果在压力测试中达到了预期结果，就可以放到预生产环境中，然后进行 QA 验收，最后交付生产，整个流程是节节贯穿的管道，如果管道的某一环断开了，比如集成环境断开没有达到预期，就不应该执行下面的压力测试，原因是，将失败的集成环境版本交付交到压测环境是没有意义的。在这种节节贯穿的环境下，CI 的 PIPELINE 工具优势体现在整个环境以及流程上的使用，在交付开发的时候，能够让开发以最优的资源把任务交付到生产环境，避免了测试环节以及重复开发部署这些细节问题。轻课使用的是 jira + bitbucket + confluence 进行整体的项目管理，这也是遵循敏捷开发的流程。轻课的无状态化微服务具有无状态化的特性，即挥之即来，呼之则去。服务能够快速上线，快速下线，而且不会对其他系统造成影响，同时这也意味着服务不会做任何本地落地存储，包括日志。资源隔离，因为如果你同时启 50 个服务，不可能一一配置，这时候你需要考虑自己服务方向的途径，怎么样能够快速实现。轻课使用容器化技术就能很好的解决这个问题。SOA 和微服务的区别在哪里？其中有一个很大区别就是微服务是无状态化，SOA 是有状态的，尤其是在 SOA 基于长连接的模式。而在青云上很适合做这种无状态化，因为青云是秒级启动，按秒计费，另外一点是批量启动，支持轻量级的持久，NFS 挂载；另外一个优势是，内网数据传输免费，这意味着从轻课的容器仓库拉到轻课主机的时候，流量消耗是免费的，而且速度特别快。持久层包括数据可能落地到数据源，文件落地到硬盘，有些公司把日志落地到硬盘，而轻课是基于容器的 log opts 模式，直接打到轻课日志服务器上，再由日志服务器转发到相关的数据检索，比如说轻课用的是 Spark 进行检索，或者打到 kafka 连接下一步的 Spark 平台进行更多数据分析。轻课遵循一个微服务只连一个数据源的原则进行配置，这个原理是在微服务多的情况，可能会产生网状交集这种架构，在这种情况下，如果一个微服务连接多个数据源，那么在一个数据源出现瓶颈的时候，就很难快速定位到底是哪个服务给它造成了压力瓶颈，而如果单个微服务只连接一个数据源，那么在运维成本上会节约更多。对于会话与连接，为什么业界推崇设计的时候选择以 RESTful 方案，首先因为它是无状态化的，可以间接实现去中心化的思想，你这个是否是自制，如果自制那么上下游会不会影响其他的节点，这是都是无状态的细节。关于基础设施的三个思考关于基础设施的三个思考，也是因为轻课在部署微服务时候会和基础设施有一些联
系。第一，系统资源层的，在硬件上，包括硬盘空间、CPU、内存等的。在一台服务器上轻课适合部署多少个容器，这时候就需要有精确的计算，以及需要以容器方式约束每个容器最高的使用上限。在这种情况下，轻课就需要一个压力测试，让所有压力变得可测。轻课可以通过手动也可以通过编排工具，如 K8s、Mesos、Swarm 进行编排。另外是在 docker 层，docker 层本身是虚拟化，如果在云主机上再进行虚拟化的话，是否会造成性能的问题呢？经过测试，轻课发现这种情况下确实会造成性能损失，在一些特殊的情况下，性能损失达到 60%到70%。但在轻课团队的实践过程当中，性能并不是轻课主要考虑的因素，轻课更看重容器化部署的方便性，其带来的弹性和快速负载可以弥补在性能上的一些问题。最后，关于基础架构的 docker 服务。因为微服务实践以及容器化是和 DevOps 结合的，因此如果只是针对服务发现以及这种伸缩意义不大。关于去中心化，轻课典型的微服务框架是从外部的 LB 开始，LB 在青云上是一个集群，一个集群到一个反代服务器，反带服务器在国内比较常见的有两种一个是 nginx 解决方案，第二个是基于 HAProxy 的解决方案，这两种方案都是可以作为无状态化的被植入在青云的云主机里。需要的时候可以随时加入，前端绑定你的 LB 就可以。API 网关，这在整个微服务架构体系中是最重要的，因为它已经不是基础架构层的东西，它是业务层的东西，所有的 reverse 形式。比如你有一千个微服务，每个有不同的网关，如何注册到那些网关向外暴露，这个是需要 API 网关考虑的，API 网关实现跟底层监控及流量控制有一定关系，这就是去中心化，从网状结构变成放射性的结构。内部协调也会产生去中心化，比如说用户服务器需要调用支付服务器，实际上这是两个内网的微服务进行通信，这种情况下轻课也是希望从网状结构变成放射性去中心化的结构。轻课实现这种去中心化是通过青云内部的 LB 挂载到一个反弹服务器上，再从反弹服务器挂载这种 microservice，原因是业务上的压力，有可能不是来自外部，而是由内部引起的，比如说一个定时器的任务在一瞬间启动的时候，可能造成内部其他服务器受到压力冲击，因此内部也要考虑这种压力的情况。微服务本身是基于分布式 SOA 的实现方式，带有三高属性。在 API 网关层熔断报警是微服务实现的主要方式。API 可以通知当前流量到弹性控制中心以及实现新的容器的快速上线。另外，怎么样从服务发现层把新的服务快速挂载到你 API 网关呢？目前有一个基于反代注册或者用 DNS 这种模式动态修改你配置文件的解决方案。但这种方法会造成一个问题，在 nginx 高并发或者高连接的情况下，你只用 reload 的方法加载新的配置的时候，可能造成网关短暂的卡顿甚至停止，这时候就有一种新的解决思路，以 DNS 作为服务发现的方法，这种方法比较适合微服务架构。监控方案，微服务监控是比较新的一个领域，传统解决方案是基于有状态性可以绑定地址的监控，假如我瞬间启动 50 个新服务，如何将这些服务快速绑定到监控服务器上进行监控呢？有一种方法就是在微服务的内部装一个类似于心跳检测的接口，让你的监控服务器一直刷 API 层面的心跳，但就像前位嘉宾所说的，这种监控超出了基础设施层的监控，而是更多从业务和实
现上进行监控。轻课在青云上的配置流程比较简单，首先是 docker 的预装，基于 API 网关的配置和选择，封装 QingCloud 的 API，包括启动机器、创建机器、停止机器这几个过程，加入监控机制和阈值，阈值可以根据你当前的弹性属性进行设置。轻课打造了一个自己的 API 网关。为什么呢？原因有三个：第一，因为目前市面上的 API 网关比较重；第二，市面上的 API 网关里面的功能有些不是轻课需要；第三，如果 API 网关不作为微服务部署的话，它可能会产生有状态以及一些其他的问题，比如它本身是否高可用，是否可监测，这些问题都是轻课在实践中发现的。所以在部署微服务的时候，轻课是以微服务来考虑轻课的 API 网关，它虽然贴近于基础架构层面，但是轻课本身把它当成一个微服务去理解。轻课尝试制作了自己的第一个 API 网关，第一个版本从开发到上线用了四天，实现了包括代理的模式，反代 API 权限的管理代理，以及 API 管理，通过性能测试，因为它是打通内网和的唯一出口，这种情况下它的性能指标就非常关键，轻课得出结论是，在物理机上跑程序比在 docker 层以及虚拟层跑 docker 更快，因此轻课选择的架构方案是在某些物理机上架 API 网关作为轻课固定的服务，通过弹性计算启用更多的基于云主机的 API 网关。关于编排关于编排。现在 Rancher 已经全面支持 QingCloud 的 API，这件事非常令人激动。首先 Rancher 是一个管理编排平台的平台，它集成了很多现在比较热门解决方案，像 K8s、Mesos 以及他自己本身的方案。什么时候上编排服务呢？前期轻课是没有上编排的，因为前期编排对轻课来说就是手动部署和调整的工具，在还没有这么多并发流量情况下，过早的上编排，可能会增加你运维成本，在轻课手动编排的成本高于自动化编排运维成本的时候，轻课就选择上了编排。轻课之所以叫轻课，是因为轻课的架构理念就是：轻，选择最轻的架构。因此轻课选择 Swarm Cluster。首先 Swarm 是没有服务发现机制的，这也就给轻课了一个可以选择自己所需要的服务发现机制的机会。本文总结自轻课 CTO 黄曦在 QingCloud Insight 2017 中的演讲。黄曦，轻课 CTO，美国加州大学计算机科学系硕士，研究方向偏向与后端高负载，高可用架构。曾就职于美国硅谷某著名互联网金融公司，担任全栈工程师，对 Scala、clojure 等函数式语言有深入研究。如果你也想像轻课一样尝试在公有云上部署 Docker 方案，不妨在 QingCloud 控制台上试用这项 SDN 网络直通服务，它可以帮助你大幅提升 Docker 性能及网络配置易用性。SDN 网络直通的所有组件及功能均不计费。- FIN -
