微服务架构的中国式落地

前言

近年，Spring Cloud俨然已经成为微服务开发的主流技术栈，在国内开发者社区很是火爆。我近年一直在一线互联网公司（携程，拍拍贷等）开展微服务架构实践，根据我我的的一线实践经验和我平时对Spring Cloud的调研，我认为Spring Cloud技术栈中的有些组件离生产级开发尚有必定距离。，比方说Spring Cloud Config和Spring Cloud Sleuth都是Pivotal自研产品，还没有获得大规模企业级生产应用，不少企业级特性缺失（具体见我后文描述）。另外Spring Cloud体系还缺失一些关键的微服务基础组件，好比Metrics监控，健康检查和告警等。因此我在参考Spring Cloud微服务技术栈的基础上，结合自身的实战落地经验，也结合国内外一线互联网公司（例如Netflix，点评，携程，Zalando等）的开源实践，综合提出更贴近国内技术文化特点的轻量级的微服务参考技术栈。但愿这个参考技术栈对一线的架构师（或者是初创公司）有一个好的指导，可以少走弯路，快速落地微服务架构。

这个参考技术栈和整体架构以下图所示：

主要包含11大核心组件，分别是：

核心支撑组件:

1. 服务网关Zuul

2. 服务注册发现Eureka+Ribbon

3. 服务配置中心Apollo

4. 认证受权中心Spring Security OAuth2

5. 服务框架Spring MVC/Boot

监控反馈组件:

1. 数据总线Kafka

2. 日志监控ELK

3. 调用链监控CAT

4. Metrics监控KairosDB

5. 健康检查和告警ZMon

6. 限流熔断和流聚合Hystrix/Turbine

2、核心支撑组件

2.1 服务网关Zuul

2013年左右，infoq曾经对前Netflix架构总监Adrian Cockcroft有过一次专访[附录1]，其中有问Adrian：“Netflix开源这么多项目，你认为哪个是最不可或缺的(MOST Indispensable)”，Adrian回答说：“在NetflixOSS开源项目中，有一个容易被忽略，可是Netflix最强大的基础服务之一，它就是Zuul网关服务。Zuul网关主要用于智能路由，同时也支持认证，区域和内容感知路由，将多个底层服务聚合成统一的对外API。Zuul网关的一大亮点是动态可编程，配置能够秒级生效”。从Adrian的回答中，咱们能够感觉到Zuul网关对微服务基础架构的重要性。

Zuul在英文中是一种怪兽，星际争霸中虫族里头也有Zuul，Netflix为网关起名Zuul，寓意看门神兽

Zuul网关在Netflix通过生产级验证，在归入Spring Cloud体系以后，在社区中也有众多成功的应用。Zuul网关在携程（日流量超50亿），拍拍贷等公司也有成功的落地实践，是微服务基础架构中网关一块的首选。其它开源产品像Kong或者Nginx等也能够改造支持网关功能，可是较复杂门槛高一点。

Zuul网关虽然不彻底支持异步，可是同步模型反而使它简单轻量，易于编程和扩展，固然同步模型须要作好限流熔断（和限流熔断组件Hystrix配合），不然可能形成资源耗尽甚至雪崩效应（cascading failure）。

2.2 服务注册发现Eureka + Ribbon

针对微服务注册发现场景，社区里头的开源产品当中，通过生产级大流量验证的，目前只有Netflix Eureka一个，它也已经归入Spring Cloud体系，在社区中有众多成功应用，例如携程Apollo配置中心也是使用Eureka作软负载。其它产品如Zookeeper/Etcd/Consul等，都是比较通用的产品，还须要进一步封装定制才可生产级使用。Eureka支持跨数据中心高可用，但它是AP最终一致系统，不是强一致性系统。

Eureka是阿基米德洗澡时发现浮力原理时发出的惊叹声，在微服务中寓意发现

Ribbon是能够和Eureka配套对接的客户端软负载库，在Eureka的配合下可以支持多种灵活的动态路由和负载均衡策略。内部微服务直连能够直接走Ribbon客户端软负载，网关上也能够部署Ribbon，这时网关至关于一个具备路由和软负载能力的超级客户端。

2.3 服务配置中心Apollo

Spring Cloud体系里头有个Spring Cloud Config产品，可是功能远远达不到生产级，只能小规模场景下用，中大规模企业级场景不建议采用。携程框架研发部开源的Apollo是一款在携程和其它众多互联网公司生产落地下来的产品，开源两年多，目前在github上有超过4k星，很是成功，文档齐全也是它的一大亮点，推荐做为企业级的配置中心产品。Apollo支持完善的管理界面，支持多环境，配置变动实时生效，权限和配置审计等多种生产级功能。Apollo既能够用于链接字符串等常规配置场景，也可用于发布开关（Feature Flag）和业务配置等高级场景。

阿波罗是希腊神话中太阳神的意思

2.4 认证受权中心Spring Security OAuth2

目前开源社区尚未特别成熟的微服务安全认证中心产品，以前我工做过的一些中大型互联网公司，好比携程，惟品会等，在这一块基本都是定制自研的，可是对通常企业来讲，定制自研仍是有门槛的。OAuth2是一种基于令牌Token的受权框架，已经获得众多大厂（Google, Facebook, Twitter, Microsoft等）的支持，能够认为是事实上的微服务安全协议标准，适用于开放平台联合登陆，现代微服务安全（包括单页浏览器App/无线原生App/服务器端WebApp接入微服务，以及微服务之间调用等场景），和企业内部应用认证受权(IAM/SSO)等多种场景。

Spring Security OAuth2是Spring Security基础上的一个扩展，支持四种主要的OAuth2 Flows，基本能够做为微服务认证受权中心的推荐产品。可是Spring Security OAuth2还只是一个框架，不是一个端到端的开箱即用的产品，企业级应用仍需在其上进行定制，例如提供Web端管理界面，对接企业内部的用户认证登陆系统，使用Cache缓存令牌，和微服务网关对接等，才能做为生产级使用。在这里给你们推荐一个架构交流群650385180，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，如下的知识体系图也是在群里获取。相信对于已经工做和遇到技术瓶颈的码友，在这个群里必定有你须要的内容。

2.5 服务框架Spring Boot

Spring能够说是史上最成功的Web App/API开发框架之一，它融入了Java社区中多年来沉淀下来的最佳实践，虽然有将近15年历史，但目前的社区活跃度仍呈上升趋势。Spring Boot在Spring的基础上进一步打包封装，提供更贴心的Starter工程，自启动能力，自动依赖管理，基于代码的配置等特性进一步下降接入门槛。另外Spring Boot也提供actuator这样的生产级监控特性，支持DevOps研发模式，它是微服务开发框架的推荐首选。

REST契约规范Swagger和Spring有比较好的集成，使得Spring也支持契约驱动开发(Contract Driven Development)模型。对于一些中大规模的企业，若是业务复杂团队较多，考虑到互操做性和集成成本，建议采用契约驱动开发模型，也就是开发时先定义Swagger契约，而后再经过契约生成服务端接口和客户端，再实现服务端业务逻辑，这种开发模型可以标准化接口，下降系统间集成成本，对于多团队协同并行开发很是重要。

Spring Boot Logo

3、监控反馈组件

3.1 数据总线Kafka

最初由Linkedin研发并在其内部大规模成功应用，而后在Apache上开源的Kafka，是业内数据总线(Databus)一块的标配，几乎每一家互联网公司均可以看到Kafka的身影。Kafka堪称开源项目的一个经典成功案例，其创始人团队从Linkedin离职后还专门成立了一家叫confluent的企业软件服务公司，围绕Kafka周边提供配套和增值服务。在监控一块，日志和Metrics等数据能够经过Kafka作收集、存储和转发，至关于中间增长了一个大容量缓冲，可以应对海量日志数据的场景。除了日志监控数据收集，Kafka在业务大数据分析，IoT等场景都有普遍应用。若是对Kafka进行适当定制加强，还能够用于传统消息中间件场景。

Kafka的特性是大容量，高吞吐，高可用，数据可重复消费，可水平扩展，支持消费者组等。Kafka尤为适用于不严格要求实时和不丢数据的大数据日志场景。

Kafka创始人三人组，离开Linkedin后，创立了基于Kafka的创业公司Confluent

3.2 日志监控ELK

ELK（ElasticSearch/Logstash/Kibana）是日志监控一块的标配技术栈，几乎每一家互联网公司均可以看到ELK的身影，据称携程是国内ELK的最大用户，每日增量日志数据量达到80~90TB。ELK已经很是成熟，基本上是开箱即用，后续主要的工做在运维、治理和调优。ELK通常和Kafka配套使用，由于日志分词操做仍是比较耗时的，Kafka主要做为前置缓冲，起到流量消峰做用，抵消日志流量高峰和消费（分词建索引）的不匹配问题。一旦反向索引创建，日志检索是很是快的，因此日志检索快和灵活是ElasticSearch的最大亮点。另外ELK还有大容量，高吞吐，高可用，可水平扩容等企业级特性。

创业公司起步期，考虑到资源时间限制，调用链监控和Metrics监控能够不是第一优先级，可是ELK是必须搭一套的，应用日志数据必定要收集并创建索引，基本可以覆盖大部分Trouble Shooting场景（业务，性能，程序bug等）。另外用好ELK的关键是治理，须要制定一些规则（好比只收集Warn级别以上日志），对应用的日志数据量作好监控，不然开发人员会滥用，什么垃圾数据都往ELK里头丢，形成大量空间被浪费，严重的还可能形成性能可用性问题。

3.3 调用链监控CAT

Spring Cloud支持基于Zipkin的调用链监控，我我的基于实践经验认为Zipkin还不能算一款企业级调用链监控产品，充其量只能算是一个半成品，不少重要的企业级特性缺失。Zipkin最先是由Twitter在消化Google Dapper论文的基础上研发，在Twitter内部有较成功应用，可是在开源出来的时候把很多重要的统计报表功能给阉割了（由于依赖于一些比较重的大数据分析平台），只是开源了一个半成品，能简单查询和呈现可视化调用链，可是细粒度的调用性能数据报表没有开源。

Google大体在2007年左右开始研发称为Dapper的调用链监控系统，但在远远早于这个时间（大体在2002左右），eBay就已经有了本身的调用链监控系统CAL(Centralized Application Logging)，Google和eBay的设计思路大体相同，可是也有一些差异。CAL在eBay有大规模成功应用，被称为是eBay的四大神器之一（另外三个是DAL，Messaging和SOA）。开源调用链监控系统CAT的做者吴其敏（我曾经和他同事，习惯叫他老吴），曾经在eBay工做近十年，期间深刻消化吸取了CAL的设计。2011年后老吴离开eBay去了点评，用三年时间在点评再造了一款调用链监控产品CAT（Centralized Application Tracking），CAT具备CAL的基因和影子，同时也融入了老吴在点评的探索实践和创新。

CAT是一款更完整的企业级调用链监控产品，甚至已经接近一个APM（Application Performance Management）产品的范畴，它不只支持调用链的查询和可视化，还支持细粒度的调用性能数据统计报表，这块是CAT和市面上其它开源调用链监控产品最本质的差别点，实际上开发人员大部分时间用CAT是看性能统计报表（主要是CAT的Transaction和Problem报表），这些报表至关于给了开发人员一把尺子，能够自助测量并持续改进应用性能。另外CAT还支持应用报错大盘，自助告警等功能，也是企业级监控很是实用的功能。

CAT在点评，携程，陆金所，拍拍贷等公司有成功落地案例，由于是国产调用链监控产品，界面展现和功能等更契合国内文化，更易于在国内公司落地。我的推荐CAT做为微服务调用链监控的首选。至于社区里头有人提到CAT的侵入性问题，我以为是要一分为二看，有利有弊，有耦合性可是性能更好，通常企业中基础架构团队会使用CAT统一为基础组件埋点，开发人员通常不用本身埋点；另外企业用了一款调用链监控产品之后，通常是不会换的，开发人员用习惯就行了，侵入不是大问题。

3.4 Metrics监控KairosDB

除了日志和调用链，Metrics也是应用监控的重要关注点。互联网应用提倡度量驱动开发（Metrics Driven Development），也就是说开发人员不只要关注功能实现，作好单元测试（TDD），还要作好业务层（例如注册，登陆和下单数等）和应用层（例如调用数，调用延迟等）的监控埋点，这个也是DevOps（开发即运维）理念的体现，DevOps要求开发人员必须关注运维需求，监控埋点是一种生产级运维需求。

Metrics监控产品底层依赖于时间序列数据库（TSDB），最近比较热的开源产品有Prometheus和InfluxDB，社区用户数量和反馈都不错，能够采纳。可是这些产品分布式能力比较弱，定制扩展门槛比较高，通常建议刚起步量不大的公司采用。若是企业业务和团队规模发展到必定阶段，建议考虑支持分布式能力的时间序列监控产品，例如KairosDB或者OpenTSDB，我本人对这两款产品都有一些实践经验，KariosDB基于Cassandra，相对更轻量一点，建议中大规模公司采用，若是大家公司已经采用Hadoop/HBase，则OpenTSDB也是不错选择。

KairosDB通常也和Kafka配套使用，Kafka做为前置缓冲。另外注意使用KariosDB打点的话tag的值不能太离散，不然会有查询性能问题，这个和KariosDB底层存储结构有关系。Grafana是Metrics展现标配，能够和KariosDB无缝集成。

Grafana是Metrics展现标配，和主流时间序列数据库均可以集成

3.5 健康检查和告警ZMon

除了上述监控手段，咱们仍须要健康检查和告警系统做为配套的监控手段。ZMon是德国电商公司Zalando开源的一款健康检查和告警平台，具有强大灵活的监控告警能力。ZMon本质上能够认为是一套分布式监控任务调度平台，它提供众多的Check脚本（也能够本身再定制扩展），可以对各类硬件资源或者目标服务（例如HTTP端口，Spring的Actuator端点，KariosDB中的Metrics，ELK中的错误日志等等）进行按期的健康检查和告警，它的告警逻辑和策略采用Python脚本实现，开发人员能够实现自助式告警。ZMon同时适用于系统，应用，业务，甚至端用户体验层的监控和告警。

ZMon分布式监控告警系统架构，底层基于KairosDB时间序列数据库

3.6 限流熔断和流聚合Hystrix+Turbine

2010年左右，Netflix也饱受分布式微服务系统中雪崩效应（Cascading Failure）的困扰，因而专门启动了一个叫作弹性工程的项目来解决这个问题，Hystrix就是弹性工程最终落地下来的一个产品。Hystrix在Netflix微服务系统中大规模推广应用后，雪崩效应问题基本获得解决，整个体统更具弹性。以后Netflix把Hystrix开源贡献给了社区，短时间得到社区的大量正面反馈，目前Hystrix在github上有超过1.3万颗星，听说支持奥巴马总统选举的系统也曾使用Hystrix进行限流熔断保护[参考附录2]，可见限流熔断是分布式系统稳定性的强需求，Netflix很好的抓住了这个需求并给出了通过生产级验证的解决方案。Hystrix已经被归入Spring Cloud体系，它是Java社区中限流熔断组件的首选（目前还看不到第二个更好的产品）。

Turbine是和Hystrix配套的一个流聚合服务，可以对Hystrix监控数据流进行聚合，聚合之后能够在Hystrix Dashboard上看到集群的流量和性能状况。

Hystrix在英文中是豪猪兽的意思，豪猪兽经过身上的刺保护本身，Netflix为限流熔断组件起名Hystrix，寓意Hystrix可以保护微服务调用。

4、结论

1. 技术栈没有好坏之分，只有适合一说。本文推荐的技术栈主要基于我我的的实践和总结，可是未必适合全部场景，毕竟每一个企业的上下文各不相同。做为架构师你能够参考我推荐的技术栈，但不可拘泥照搬，你必须在深刻理解分布系统原理的基础上，再结合企业实际场景灵活应用。

2. 本文推荐的技术栈主要面向微服务基础架构，在整个互联网基础技术平台体系中，还有消息，任务，数据访问层，发布系统，容器云平台，分布式事务，分布式一致性，测试，CI/CD等其它重要主题。