一个小团队的微办事架构革新之路

来源丨Dean

deanwangpro.com/2019/02/18/road-of-microservice

 概   述 

微办事能否合适小团队是个见仁见智的问题。回归现象看素质，跟着营业复杂度的进步，单体应用越来越庞大，就仿佛一个类的代码行越来越多，分而治之，切成多个类应该是更好的处理办法，所以一个庞大的单体应用分出多个小应用也更契合那种分治的思惟。当然微办事架构不该该是一个小团队一起头就该考虑的问题，而是渐渐演化的成果，隆重过度设想尤为重要。

 单体应用时代 

早期开发只要两小我，考虑微办事之类的都是多余。不外因为受前公司影响，最后就决定了前后端别离的道路，因为不需要考虑SEO的问题，索性就做成了SPA单页应用。多说一句，前后端别离也纷歧定就不克不及办事端衬着，例如电商系统或者一些匿名即可拜候的系统，加一层薄薄的View层，无论是php仍是用Thymeleaf都是不错的选择。

摆设架构上，利用 Nginx代办署理前端 HTML资本，在领受恳求时按照途径反向代办署理到 server的 8080端口实现营业。

 接口定义 

接口根据尺度的Restful来定义：

版本，同一跟在 /api/后面，例如 /api/v2

以资本为中心，利用复数表述，例如 /api/contacts，也能够嵌套，如 /api/groups/1/contacts/100

url 中尽量不利用动词，理论中发现做到那一点实的比力难，每个研发人员的思绪纷歧致，起的名字也光怪陆离，都需要在代码Review中笼盖。

动做撑持， POST/PUT/DELELE/GET ，那里有一个坑， PUT和 PATCH都是更新，但是PUT是全量更新而PATCH是部门更新，前者若是传入的字段是空（未传也视为空）那么也会被更新到数据库中。目前我们固然是利用PUT但是忽略空字段和未传字段，素质上是一种部门更新，那也带来了一些问题，好比确有置空的营业需要特殊处置。

接口通过swagger生成文档供前端同事利用。

 持续集成（CI） 

团队初始成员之前都有在大团队共事的履历，所以关于量量管控和流程办理都有一些配合的要求。因而在开发之初就引入了集成测试的系统，能够间接开发针对接口的测试用例，同一施行并计算笼盖率。

一般来说代码主动施行的都是单位测试 (Unit Test)，我们之所以叫 集成测试是因为测试用例是针对 API的，而且包罗了数据库的读写，MQ的操做等等，除了外部办事的依赖根本都是契合实在消费场景，相当于把 Jmeter的工作间接在Java层面做掉了。那在开发初期为我们供给了十分大的便当性。但值得留意的是，因为数据库以及其他资本的引入，数据筹办以及数据清理时要考虑的问题就会更多，例如若何控造并行使命之间的测试数据互不影响等等。

为了让那一套流程能够主动化的运做起来， 引入 Jenkins也是天经地义的工作了。

开发人员提交代码进入 gerrit中，Jenkins被触发起头编译代码并施行集成测试，完成后生成测试陈述，测试通过再由 reviewer停止代码review。在单体应用时代如许的CI架构已经足够好用，因为有集成测试的笼盖，在连结API兼容性的前提下停止代码重构城市变得更有自信心。

然而微办事时代到来了！

 办事拆分原则 

从数据层面看，最简单的体例就是看数据库的表之间能否有比力少的联系关系。例如最容易别离的一般来说都是用户办理模块。若是从范畴驱动设想（DDD）看，其实一个办事就是一个或几个相联系关系的范畴模子，通过少量数据冗余划清办事鸿沟。单个办事内通过范畴办事完成多个范畴对象协做。当然DDD比力复杂，要求范畴对象设想上是充血模子而非贫血模子。从理论角度讲，充血模子关于大部门开发人员来说难度十分高，什么代码应该属于行为，什么属于范畴办事，良多时候十分考验人员程度。

办事拆分是一个大工程，往往需要几个对营业以及数据最熟悉的人一路讨论，以至要考虑到团队构造，最末的效果是办事鸿沟明晰， 没有环形依赖和制止双向依赖。

 框架选择 

因为之前的单体办事利用的是 spring boot，所以框架天然而的选择了 spring cloud。其实小我认为微办事框架不该该限造手艺与语言，但消费理论中发现无论 dubbo仍是 spring cloud都具有侵入性，我们在将 nodejs应用融入 spring cloud系统时就发现了许多问题。也许将来的service mesh才是更合理的开展道路。

那是典型的Spring Cloud的利用办法：

zuul 做为gateway，分发差别客户端的恳求到详细service

erueka 做为注册中心，完成了办事发现和办事注册

每个 service包罗 gateway都自带了 Hystrix供给的限流和熔断功用

service 之间通过 feign和 ribbon互相挪用，feign现实上是屏障了service对erueka的操做

上文说的一旦要融入异构语言的 service，那么办事注册，办事发现，办事挪用，熔断和限流都需要本身处置。再有关于 zuul要多说几句，Sprin Cloud供给的 zuul对 Netflix版本的做了裁剪，去掉了动态路由功用（Groovy实现），别的一点就是 zuul的性能一般，因为接纳同步编程模子，关于 IO密集型等后台处置时间长的链路十分容易将 servlet的线程池占满，所以若是将 zuul与次要service放置在统一台物理机上，在流量大的情况下，zuul的资本消耗十分大。现实测试也发现颠末zuul与间接挪用service的性能丧失在30%摆布，并发压力大时更为明显。如今 spring cloud gateway是pivotal的主推了，撑持异步编程模子，后续架构优化也许会接纳，或是间接利用Kong那种基于nginx的网关来供给性能。当然同步模子也有长处，编码更简单，后文将会提到利用ThreadLocal若何成立链路跟踪。

 架构革新 

颠末大半年的革新以及新需求的参加，单体办事被不竭拆分，最末构成了 10余个微办事，而且搭建了 Spark用于 BI。初步构成两大致系，微办事架构的在线营业系统 (OLTP) + Spark大数据阐发系统(OLAP)。数据源从只要Mysql增加到了 ES和 Hive。大都据源之间的数据同步也是值得一说的话题，但内容太多不在此文赘述。

办事拆分接纳间接割接的体例，数据表也是整体迁徙。因为几次大革新的晋级申请了停服，所以步调相对简单。若是需要不断服晋级，那么应该接纳先双写再逐渐切换的体例包管营业不受影响。

 主动化摆设 

与 CI比起来，持续交付（CD）实现更为复杂，在资本不敷的情况我们尚未实现 CD，只是实现施行了主动化摆设。

因为消费情况需要通过跳板机操做，所以我们通过 Jenkins生成 jar包传输到跳板机，之后再通过 Ansible摆设到集群。

简单粗暴的摆设体例在小规模团队开发时仍是够用的，只是需要在摆设前包管测试（人工测试 + 主动化测试）到位。

 链路跟踪 

开源的全链路跟踪良多，好比 spring cloud sleuth + zipkin，国内有美团的 CAT等等。其目标就是当一个恳求颠末多个办事时，能够通过一个固定值获取整条恳求链路的行为日记，基于此能够再停止耗时阐发等，衍生出一些性能诊断的功用。不外关于我们而言，首要目标就是trouble shooting，出了问题需要快速定位异常呈现在什么办事，整个恳求的链路是如何的。

为了让处理计划轻量，我们在日记中打印RequestId以及TraceId来标识表记标帜链路。RequestId在gateway生成暗示独一一次恳求，TraceId相当于二级途径，一起头与RequestId一样，但进入线程池或者动静队列后，TraceId会增加标识表记标帜来标识独一条途径。举个例子，当一次恳求会向MQ发送一个动静，那么那个动静可能会被多个消费者消费，此时每个消费线程城市本身生成一个TraceId来标识表记标帜消费链路。参加TraceId的目标就是为了制止只用RequestId过滤出太多日记。实现如图所示，

简单的说，通过 ThreadLocal存放 API RequestContext 串联单办事内的所有挪用，当跨办事挪用时，将API RequestContext信息转化为Http Header，被挪用方获取到Http Header后再次构建API RequestContext放入ThreadLocal，反复轮回包管 RequestId和 TraceId不丧失即可。若是进入MQ，那么API RequestContext信息转化为Message Header即可（基于Rabbitmq实现）。

当日记汇总到日记系统后，若是呈现问题，只需要捕捉发作异常的RequestId或是TraceId即可停止问题定位

颠末一年来的利用，根本能够满足绝大大都 trouble shooting的场景，一般半小时内即可定位到详细营业。

 运维监控 

在容器化之前，接纳 telegraf + influxdb + grafana的计划。telegraf做为探针搜集 jvm，system，mysql等资本的信息，写入 influxdb，最末通过 grafana做数据可视化。spring boot actuator能够共同 jolokia表露 jvm的 endpoint。整个计划零编码，只需要花时间设置装备摆设。

接着，容器化时代又到来了！

 架构革新 

因为在做微办事之初就方案了容器化，所以架构并未大动，只是每个办事城市成立一个 Dockerfile用于创建 docker image

涉及变革的部门包罗：

CI中多了构建docker image的步调

主动化测试过程中将数据库晋级从应用中剥离零丁做成docker image

消费顶用k8s自带的service替代了eruka

理由下文逐个道来。

 Spring Cloud + k8s交融 

我们利用的是 Redhat的 Openshift，能够认为是 k8s企业版，其自己就有 service的概念。一个 service下有多个 pod，pod内便是一个可办事单位。service之间互相挪用时k8s会供给默认的负载平衡控造，倡议挪用方只需要写被挪用方的serviceId即可。那一点和spring cloud fegin利用ribbon供给的功用千篇一律。也就是说办事治理能够通过k8s来处理，那么为什么要替代呢？其实上文提到了，Spring Cloud手艺栈关于异构语言的撑持问题，我们有许多BFF（Backend for Frontend）是利用 nodejs实现的，那些办事要想交融到 Spring Cloud中，办事注册，负载平衡，心跳查抄等等都要本身实现。若是以后还有其他语言架构的办事参加进来，那些轮子又要重造。基于此类原因综合考量后，决定接纳 Openshift所供给的收集才能替代 eruka。

因为当地开发和联调过程中仍然依赖eruka，所以只在消费上通过设置装备摆设参数来控造，

eureka.client.enabled 设置为 false，停行各办事的eureka注册

ribbon.eureka.enabled 设置为 false，让ribbon不从eureka获取办事列表

以办事foo为例， foo.ribbon.listofservers 设置为  http://foo:8080，那么当一个办事需要利用办事foo的时候，就会间接挪用到 http://foo:8080

 CI的革新 

CI的革新次要是多了一部编译 docker image并打包到 Harbor的过程，摆设时会间接从 Harbor拉取镜像。另一个就是数据库的晋级东西。之前我们利用 flyway做为数据库晋级东西，当应用启动时主动施行 SQL脚本。跟着办事实例越来越多，一个办事的多个实例同时晋级的情况也时有发作，固然 flyway是通过数据库锁实现了晋级过程不会有并发，但会招致被锁办事启动时间变长的问题。从现实晋级过程来看，将可能发作的并发晋级变成单一历程可能更靠谱。此外后期分库分表的架构也会使随应用启动主动晋级数据库变的困难。综合考量，我们将晋级使命做了拆分，每个办事都有本身的晋级项目并会做容器化。在利用时，做为 run once的东西来利用，即 docker run-rm的体例。而且后续也撑持了设定目的版本的功用，在私有化项目标跨版本晋级中起到了十分好的效果。

至于主动摆设，因为办事之间存在上下流关系，例如 config，eruka等属于根本办事被其他办事依赖，摆设也产生了先后挨次。基于 Jenkins做 pipeline能够很好的处理那个问题。

 小   结 

其实以上的每一点都能够深切的写成一篇文章，微办事的架构演进涉及到开发，测试和运维，要求团队内多工种慎密合做。分治是软件行业处理大系统的不贰秘诀，做为小团队我们并没有自觉逃新，而是在开展的过程通过办事化的体例处理问题。从另一方面我们也体味到了微办事关于人的要求，以及关于团队的挑战都比过去要高要大。将来仍需摸索，演进仍在路上。