刘地生|微服务的实践-阿里云开发者社区

一. 为什么大家都在谈微服务？

背景：随着互联网业务的极速增长，不仅仅体现在用户的增长，你的代码规模也会有直观体现。伴随系统规模的上升，传统的单体架构就像一艘不断变大吨位的巨轮，变得越来越笨重。系统规模所带来的挑战也不断影响着相关的参与者。开发者开发一个新功能、重构一小段代码、引入一个新技术变得不再敏捷可控。测试者的回归测试边界难以琢磨。部署一次变得小心翼翼或提心吊胆。这些都让应对变化变得迟钝。

是的，那个老头(Martin Flower)又出现了，又捣鼓出一个新概念【微服务】。他确实很喜欢捣鼓概念(不做过度解读) 微服务其实也不是那么新，它的提出之前，大家已经在服务化的路上走了好一会了。或者叫SOA或者叫ESB。都尝试解决服务规模导致的开发问题、重用问题、治理问题等等。当然微服务也不完全跟他们一样，至少为了适应现在的新环境提出了一些自己理念。如更快的应对变化，应对云环境的适配等等我们可以从中感知它的一些明显特点：它能独立开发、测试、部署，是一个可以独立提供某项垂直业务的完整服务，把一件事做的足够好。

二. 我们希望的微服务是什么样子

微服务已然是一个独立自治的王国。那所希望的这个王国应该是什么样子？或者说我们希望软件的乌托邦长什么样？从根本上来说微服务是一个偏向技术的架构模式，那么从技术使用方的角度来看它的方方面面。

● 学习成本：不想为了用它得先学习准备个10天半个月，这跟我爱不爱学习新东西无关
● 使用简单：不希望一个hello world比开发一个功能还艰难
● 迁移成本：已经有很多系统在维护中，不希望大动干戈，推倒重来是一定程度的犯罪（你无法保证建立的新世界比原来好）
● 易于测试：希望一个单元测试或者集成测试很快就能跑起来
● 高性能：不会有性能瓶颈，引入的负载小
● 部署简单：部署也是成本，自动化，不进行人工环境干预。适应各种环境，最大利用硬件资源
● 易于监控：完善的日志记录，出现问题能被监控、告警，对系统运行状态及各种指标能随时掌握
● 易于运维：对突发事件有运维调度能力，防止雪崩效应。可以对系统进行弹性伸缩，快速的拉起和优雅关闭等等

三. 实现微服务

必要性和需求已经提出，现在需要将空中楼阁变成一块块的技术砖头

● 微服务自身实现

服务路由、负载均衡、容错、限流、健康检查、监控、日志、网络通信、序列化、配置管理、SPI、测试等等，不过这些feature具体依赖与特定微服务框架的设计

● 部署

在当前硬件资源都在走向虚拟化的进程中，让系统部署成一个无状态进程是很有必要的，不预设环境，同时加快启动效率。这就需要对其库依赖自给自足、代码与配置隔离、系统支持优雅关闭、日志统一管理等等。比如Springboot的依赖管理及进程管理等等做的就很完善，而Docker的容器资源隔离已经快要成了事实上的标准

● 其他

数据与框架无关性、对使用者语言中立、服务的升级、分布式会话状态、事务如何处理等等。这些问题可通过中立第三方工具或服务解决，如protocol buffers、json这种扩展性良好中立的结构来对数据进行序列化，统一会话认证服务解决状态问题、事件源回溯来解决事务等等。已不单单是微服务本身的问题实现的考量及调研鉴于公司技术栈的异构多语言特性，基于契约优先gRPC与基于REST的Netflix 微服务组件集纳入我们的视野。从高性能、适合复杂环境的通用性、中立性、优雅关闭、简单易用性等比较。gRPC这种带有契约优先及基于RPC调用的框架基本可满足要求。 gRPC有什么问题？对分布式环境下的负载均衡、服务注册调用没有提供支持。基于契约所适配的代码易用性较差，业务逻辑实现被gRPC侵入、对生命周期管理的扩展较弱等等。这些都与易用性存在着Gap。如何消除这些Gap？引入gateway层，消除分布式系统的路由寻址、负载均衡、注册反注册、流量控制，增强系统的分布式环境适应能力。不对协议做破坏性再封包，实现透明兼容；抽象endpoint模型，简化调用关系和扩展生命周期。将生命周期管理进行扩展，不再局限与gRPC自己的生命周期。简化调用模型，在endpoint之间对等通信或走gateway通信。引入基于契约的代码脚手架，自动生成易用性、可读性良好的Stub、消除或减小使用gap，见下图。

整体架构

实践过程中我们的各种抉择:

◆ 代码优先 VS契约优先

代码优先意味着实现简单，能够快速执行。问题也很明显，可能绑定在具体某个语言，面对多语言环境打通成本较高。契约优先的中立性提供了一个中间桥梁，让面向多语言成为了可能，基于契约的元信息，为后续治理和演进提供的入口点。缺点是需要进行多语言适配。鉴于公司环境，团队之间异构语言的特点。我们接收契约优先带来的适配，为后面的基于元信息的使用及扩展提供空间

◆ HTTP+REST VS RPC

HTTP+REST有什么问题？给了无限的自由和想象空间，对服务约束完全靠提供者的自觉。特点是简单，对开发使用友好。当然也有自由的代价，治理起来困难，连接的无状态，缺失多路复用、服务端推送等等 RPC对通信双方定义了数据约束，连接大多基于长连接以获得性能的提升及附带的服务端推、调用链路监控埋点等等，增强了系统的附加能力。缺点是对调用端提出了新的要求。综合来看，RPC从性能、契约优先来说具有优势，如何做到扬长避短呢？有个观点叫没有什么事是加一层解决不了的。从这点出发，引入gateway层，让REST与RPC的优点进行融合，在gateway层提供REST的接入能力

◆ 客户端治理 VS 服务端治理

客户端治理需要有有注册中心来提供配置、服务端信息的寻址、负载均衡等等以确定调用最后的调用方式，客户端需要完成很多工作，在一些限制环境如移动端APP受到限制服务端治理为客户端减压，简化客户端复杂度，为限制环境下的调用提供可能。不足是调用链路多引入了一层，会产生一定的性能损耗，gateway同样带来扩展能力(如流量的管控、灰度发布、服务路由、负载均衡、健康检测等等)，及更好的client适应性出于对多环境客户端的适配性，gateway扩展的能力及治理能力，gateway的损耗我们是愿意接受的

◆ 外部管理VS进程自治管理

外部管理(如tomcat)让用户不用关注自身的起始、消亡，带来的不足是对生命周期的管理相对减弱、部署的依赖管理扩散。进程自治可以加强其对自身生命周期的管理，高内聚，不将依赖扩散。一定程度代理部署的便利及不同部署环境的适应性（如云环境）。为优雅关闭提供切入点。进一步增强对系统的可控性。从对环境适应性和对生命周期的管理能力考虑，进程自治有着不可忽略的优势，

◆ 配置与代码耦合VS配置与代码的分离

配置和代码一起带来的是开发的简单，不足也很明显，面对不同环境的，部署多套代码增加复杂度分离后优点明显真正做到只部署一套代码。配置信息按环境独立配置，不受环境制约，随时调整

四. 让微服务快速落地

当我们在说快速落地的时候，我们在说什么？可能说的是易用性。如何将易用性提速？使用者来说：是不写或写很少的额外代码，是迁移很简单，对原有系统影响最小。是测试起来不增加困难，是部署起来没有那么多依赖条件。是随时能感知系统运行状态。而这些都需要完善的工具提供支持。工具篇简化集成：如java平台下的系统大部分的类依赖都由spring管理，而Springboot更是在其基础上进一步解放了spring的使用成本。借助Springboot starter的能力，将微服务快速集成并拉起，将使用成本降低到一个注解就完成对系统的集成。经验：将注解设计成与具体框架无关性，只表示为元信息，不随意扩散依赖。然后在具体框架上完成对注解的识别（如spring里参见ImportBeanDefinitionRegistrar）

部署：基于目前虚拟化出现在各个层面，这意味着进一步获得了自动化能力。通过如docker这种工具可以快的提升部署能力

运维监控：针对自身业务，提供相应的系统支持

五. 附录

自我介绍：刘地生，融数数据基础架构部架构师。曾就职于去哪儿、百度、ONEAPM从事相关分布式系统架构设计、研发和性能优化工作。目前主要负责融数数据微服务平台的架构设计和开发工作。

问答环节

Q1：api gateway使用开源产品还是自己开发，是否有必要自己开发？

A1：gateway是自己基于netty开发的，看需求和对可控性的要求来决定是否自己开发。如果觉得开源的产品不符合你想要的要求，那自己开发也是一条没有太多选择的路。

Q2：能解释一下什么是代理，什么是存根，以及它们的关系是什么吗？

A2：这个问题不是很明白你具体指的上下文，按我个人的理解，代理是在原有事情上包装一层，但是做的事情的核心没变。存根是一种降低使用复杂度的手段，生成一些重复、复杂的代码来减少使用者的负担。存根可能会使用到代理模式。

Q3：netty也适合做实时返回的交api gateway开发？netty发布的是什么协议的api?

A3：netty跟实时不冲突，只要你是长连接，那么它就具备接收和推送的能力。关于协议你只要在实现的时候不对原协议做破坏，那么它就是一个透明的穿透。我们内部的实现中，netty工作在http2上。

Q4：你们gateway有什么功能点？单机qps多少？

A4：现阶段具备注册发现、健康检查、负载均衡、反向代理、流量控制等功能。单机QPS在空包的情况下13万，1k数据包情况下3万左右，5k数据包的情况下1万5左右

Q5：spring boot很火，版本迭代速度很快，一些模块改动很大，但这给开发和部署带来一定的困惑，并且新人如果没接触过springMVC的话很容易掉入坑里，因为自动化程度很高，很多时候错误莫名其妙，也看不到里面发生了什么，这些问题如何解决？

A5：springboot的加载机制其实是很严谨的，都是在各种condition情况满足下才会加载，部署的话其实应该比原来更简单才对，它提供的maven 打包插件打出一个jar就能进行部署。如果说坑那可能是没有按照springboot的约定实施造成的，它提供了很多机制去查看它的状态，比如各种http的endpoint，官方参考文档应该会帮上大忙。

Q6：从esb soa转微服务，原本进程内的调用关系变成了网络调用，一次rpc变成了几次或者几十次rpc，同等条件下性能损失严重。这个问题如何得到解决？

A6：任何问题都有两面性，从开发的可维护性和降低复杂度等、部署的效率，故障影响的范围等等来说，微服务有很大的优势。你提到的性能问题，可能是服务的拆分过细导致，但不管怎么拆，从一个调用被拆成几十次调用肯定是粒度有严重问题，提高性能可以从按业务单元合理拆分粒度、合理的网络规划及部署、提高微服务本身性能等方面着手。

来源：中生代技术

原文链接

刘地生|微服务的实践

微服务

热门文章

最新文章

相关课程

相关电子书

相关实验场景