一. 为什么大家都在谈微服务？
背景：随着互联网业务的极速增长，不仅仅体现在用户的增长，你的代码规模也会有直观体现。伴随系统规模的上升，传统的单体架构就像一艘不断变大吨位的巨轮，变得越来越笨重。系统规模所带来的挑战也不断影响着相关的参与者。开发者开发一个新功能、重构一小段代码、引入一个新技术变得不再敏捷可控。测试者的回归测试边界难以琢磨。部署一次变得小心翼翼或提心吊胆。这些都让应对变化变得迟钝。
是的，那个老头(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，见下图。
整体架构
实践过程中我们的各种抉择:
代码优先意味着实现简单，能够快速执行。问题也很明显，可能绑定在具体某个语言，面对多语言环境打通成本较高。
契约优先的中立性提供了一个中间桥梁，让面向多语言成为了可能，基于契约的元信息，为后续治理和演进提供的入口点。缺点是需要进行多语言适配。
鉴于公司环境，团队之间异构语言的特点。我们接收契约优先带来的适配，为后面的基于元信息的使用及扩展提供空间
HTTP+REST有什么问题？给了无限的自由和想象空间，对服务约束完全靠提供者的自觉。特点是简单，对开发使用友好。当然也有自由的代价，治理起来困难，连接的无状态，缺失多路复用、服务端推送等等
RPC对通信双方定义了数据约束，连接大多基于长连接以获得性能的提升及附带的服务端推、调用链路监控埋点等等，增强了系统的附加能力。缺点是对调用端提出了新的要求。
综合来看，RPC从性能、契约优先来说具有优势，如何做到扬长避短呢？有个观点叫没有什么事是加一层解决不了的。从这点出发，引入gateway层，让REST与RPC的优点进行融合，在gateway层提供REST的接入能力
客户端治理需要有有注册中心来提供配置、服务端信息的寻址、负载均衡等等以确定调用最后的调用方式，客户端需要完成很多工作，在一些限制环境如移动端APP受到限制
服务端治理为客户端减压，简化客户端复杂度，为限制环境下的调用提供可能。不足是调用链路多引入了一层，会产生一定的性能损耗，gateway同样带来扩展能力(如流量的管控、灰度发布、服务路由、负载均衡、健康检测等等)，及更好的client适应性
出于对多环境客户端的适配性，gateway扩展的能力及治理能力，gateway的损耗我们是愿意接受的
外部管理(如tomcat)让用户不用关注自身的起始、消亡，带来的不足是对生命周期的管理相对减弱、部署的依赖管理扩散。
进程自治可以加强其对自身生命周期的管理，高内聚，不将依赖扩散。一定程度代理部署的便利及不同部署环境的适应性（如云环境）。为优雅关闭提供切入点。进一步增强对系统的可控性。
从对环境适应性和对生命周期的管理能力考虑，进程自治有着不可忽略的优势，
配置和代码一起带来的是开发的简单，不足也很明显，面对不同环境的，部署多套代码增加复杂度
分离后优点明显真正做到只部署一套代码。配置信息按环境独立配置，不受环境制约，随时调整
- 四. 让微服务快速落地
当我们在说快速落地的时候，我们在说什么？可能说的是易用性。如何将易用性提速？
使用者来说：是不写或写很少的额外代码，是迁移很简单，对原有系统影响最小。是测试起来不增加困难，是部署起来没有那么多依赖条件。是随时能感知系统运行状态。而这些都需要完善的工具提供支持。
工具篇
简化集成：如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：任何问题都有两面性，从开发的可维护性和降低复杂度等、部署的效率，故障影响的范围等等来说，微服务有很大的优势。你提到的性能问题，可能是服务的拆分过细导致，但不管怎么拆，从一个调用被拆成几十次调用肯定是粒度有严重问题，提高性能可以从按业务单元合理拆分粒度、合理的网络规划及部署、提高微服务本身性能等方面着手。
来源：中生代技术
原文链接
