满大街微服务的年代，沪江任务调度系统独特的设计思惟

内容来源：2017年4月22日，沪江学习系统技术经理黄凯在“【沪江技术沙龙】 -- 漫谈微服务架构实践”进行《任务也是微服务——沪江任务调度系统微服务化介绍》演讲分享。IT 大咖说（id:itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：2823 | 4分钟阅读

嘉宾演讲视频地址：suo.im/4NWSu8

摘要

微服务是一种分布式解决方案，它整合了过去十年来的新概念和技术。在这个满大街都是微服务的年代，如何使用好微服务是值得研究的议题。今天我以沪江的任务调度系统为例，从架构拆分、测试、部署到监控，引伸出我厂微服务化的设计思想。

什么是微服务

微服务是一些协同工做，小而自治的服务。它是SOA的一种特殊表现形式，但在通讯协议和三方组件的选择上是不一样的，微服务的颗粒度要比SOA小。

当服务愈来愈小的时候，微服务架构的优势和缺点也就越明显。优势是服务越小就越不容易出错，性能也越高。缺点是当微服务变多的时候，对于测试人员和运维人员来讲工做量要翻倍。咱们认为若是一个服务可以在两个星期内重构，这样的颗粒度大小就是正好的。

咱们以沪江的任务调度系统举例。上图中是咱们的第一代调度系统。Task Center专门用于分发任务，并会启不少不少worker线程进行工做，架构很是简单。这种架构的问题就在于它不适宜扩展，host若是宕机了，全部业务就只能停下来等它修复，这是一个很严重的问题。针对这个问题咱们作了第二代调度系统。

首先咱们作了业务拆分。咱们把业务理解成一个工厂的流水线，有一个“Boss”专门负责接任务，而后把任务发到流水线上。Worker们从流水线上拿一个合适的任务去作，第一个worker完成后交还给流水线，下一个worker再去流水线上找合适的任务作。每个worker都对应一个不一样的DB进行存储它的状态信息，boss也有DB存储本身的状态信息，这两种DB是分开的。

这种架构拆解把一个单例的应用拆成好几个小的项目，并且每一个小的服务能够作高可用，好比启多个boss和worker。但同时也会发现其余问题：当任务特别繁忙，须要横向扩展一些worker进行工做时，只能新加一台机器，在这台机器上再启两个worker。但空闲时这些新增机器没有办法再回收了。

针对这种资源利用率不高的状况，咱们又作了一个改版。

咱们在第三代任务调度系统中引入了些中间件。Mesos是咱们引入的第一个中间件，它专门用于作资源调度，主要是帮咱们调度worker。只要经过API告诉Mesos经过什么策略来分配worker，Mesos就会自动在集群内寻找合适的资源启动任务。经过这套系统，咱们不只能完成现有业务任务，还能够扩展给其余任务型业务使用。

架构拆解过程

对于微服务的拆分，我总结为如下三点：

结构分离：要从业务的角度把任务与调度分开，把任务的生产者和消费者分开，还要把任务记录与业务逻辑也分离。

数据库分离：首先要整理出数据库的外键，从而寻找方法打破外键关系，其次就是分离共享数据。

事务分离：目前业界有两种方式，第一种是作分布式事务，但这种方法比较慢，并且设计也很复杂。另外一种方法就是追求最终一致性。选择哪一种方式还须要结合各自的业务场景进行选择。

测试

推行微服务在测试阶段也会遇到一些问题。好比TEST CASE增多、单个流程走不通、性能测试也变得很是重要。

上图为比较通用的测试金字塔，在微服务时代，金字塔的每一层测试都有不一样的测试方法，这里不一一列举。这里主要讲一些重要的测试手段。

MOCK与打桩

MOCK数据：微服务经常因为功能太小，上下依赖严重，若是要测试单个服务，必须模拟上游数据，Mock就成为常规的测试手段。这里分为外部依赖的MOCK数据和内部之间的MOCK数据。

打桩服务：常常制做Mock数据是一件无聊且繁琐的事，为了一劳永逸，经常须要作一个“打桩”服务（这里的“打桩”并非上海人说的黄牛的意思），例如作一个永远返回成功的CALLBACK服务，有的甚至能够作一个经过参数调节的智能打桩服务。

端到端测试

端到端测试的重要性：端到端测试在微服务场合是很是重要的，它能够保证业务的完整性和性能。它是指站在最终用户的角度去测试整个微服务流程，但要实现端到端的测试却很是的困难，须要整合全部微服务。这样的测试虽难必行，只有完成过端到端的测试，咱们才有勇气交付给最终用户。

端到端测试的弊端：显而易见，当服务越多，端到端就越不容易实现。另外，谁来写端到端测试用例也是不明确的。通常按照职责划分团队的公司，很难有对整个流程都很是清楚的测试人员。最后，端到端的测试时间也难以把握。

部署

进入微服务时代后，最后一个面临的挑战是部署，传统的部署方式彻底没法适应微服务的部署方式。最主要的问题就在于一台一服务到多台多服务的演变：

若是没有好的部署方式，用人力部署微服务将是一件万分可怕的事。因此必须引入无人值守的自动化部署工具。

持续集成

把镜像做为构建物：不少企业已经习惯于使用虚拟机vm来增长物理服务器的利用率。这样的好处是把操做系统隔离出来，咱们何再也不进一步，把应用和相应的环境配置文件也包含在镜像中，经过docker等容器化技术使部署变得更快。配置文件打入镜像的好处是避免配置漂移。（配置漂移是指在很是规条件下，运维人员或开发人员为了修复问题或调试，手动修改了产线配置文件却忘了恢复，使得下次发布的app和期待的配置不符）

构建PIPELINE：Pipeline是Jenkins2推荐的自动化构建方式，微服务能够用其余的方式实现自动化，只是用Pipeline能更清晰的知道每一步在干什么。下图是沪江微服务发布的一个Pipeline截图。

区分部署和上线：部署和上线是两个感念，微服务部署完毕并不等于微服务已经上线可用。它的好处在于在部署到上线之间，能够接入一些常规测试来避免由于部署或配置等缘由致使的线上故障。入下图所示，沪江在上线一个微服务的过程当中，引入了蓝绿发布，既蓝色部分是部署一个微服务到一个产线环境中，但对外的LB并无指向新部署的程序。此时能够借助自动化测试脚本或人工黑盒作最基本的测试。若是测试经过，既变成绿色部分后，再把LB指向新部署程序上实现上线过程。整个过程以下图所示。

多服务多服务器的挑战

部署最关键的问题就在于服务多，服务器也多。将面临如下问题：

海量的日志：

服务越多，就越难找到程序的调用链。若是程序的调用链找不到，引入服务治理是个好方法。咱们能够在日志中嵌入一些服务治理的信息以打点，以下图所示，咱们在每一个微服务的之中输出了Trace Id和Host IP等信息，以方便ELK聚合。

要评估某一类服务的服务器占用，还能够以服务来聚合监控。

日志跟踪与指标跟踪

日志跟踪与指标跟踪的工具大部分是使用ELK，它的好处是能够帮咱们聚合不少的数据。还有一个工具就是mesos metrics，它是mesos自带的一个小工具，它能够统计出agent上应用运行的指标。它的好处之一是能够帮咱们以服务名来聚合运行指标。

对于监控哪些指标，咱们的经验是：日志是主要的监控指标，其余还有cpu、memory和disk等。这些指标须要以服务名称而不是以物理机来聚合。

监控还能干什么？

咱们在应用上线的时候引入BVT监控；并利用监控数据进行自动触发，实现自动伸缩，让业务应用更具弹性。还有就是能对业务进行评价，经过监控回馈数据的手段来辅助业务和开发分析业务运行和服务运行的健康度。

我今天的分享就到这里，谢谢你们！