公司的背景是供应SaaS做事，对付大客户也会有定制开拓以及私有化支配。经由2年不到的韶光，技能架构经历了从单体到微做事再到容器化的过程。
单体运用时期
早期开拓只有两个人，考虑微做事之类的都是多余。不过由于受前公司影响，最初就决定了前后端分离的路线，由于不须要考虑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存放APIRequestContext串联单做事内的所有调用，当跨做事调用时，将APIRequestContext信息转化为Http Header，被调用方获取到Http Header后再次构建APIRequestContext放入ThreadLocal，重复循环担保RequestId和TraceId不丢失即可。如果进入MQ，那么APIRequestContext信息转化为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可以很好的办理这个问题。
小结
实在以上的每一点都可以深入的写成一篇文章，微做事的架构演进涉及到开拓，测试和运维，哀求团队内多工种紧密互助。分治是软件行业办理大系统的不二法门，作为小团队我们并没有盲目追新，而是在发展的过程通过做事化的办法办理问题。从另一方面我们也体会到了微做事对付人的哀求，以及对付团队的寻衅都比过去要高要大。未来仍需探索，演进仍在路上。
作者简介：王鼎， Linkflow首席架构师。11年软件研发履历，6年SaaS(基于公有云或私有云)，熟习ERP, CDP, omin渠道发卖办理方案。参与SaaS产品的大型开拓，成员400余人。在一家初创公司从零开始开拓新产品。从事SaaS架构和技能管理事情。建立新的开拓团队，专注于CDP和Martech SaaS办理方案。
声明：本文为作者投稿，版权归作者个人所有。
【END】
