微服务与SOA的关系
SOA和微服务的关系和区别，大概分为几个典型的观点：
- 微服务是SOA的实现方式：这种观点认为 SOA 是一种架构理念，而微服务是 SOA 理念的一种具体实现方法,例如，“微服务就是使用HTTP RESTful协议来实现ESB的SOA”、“使用SOA来构建单个系统就是微服务”、“微服务就是更细粒度的 SOA ”
- 微服务是去掉ESB后的SOA：这种观点认为传统SOA架构最广为人诟病的就是庞大、复杂、低效的 ESB ,因此将ESB去掉，改为轻量级的HTTP实现，就是微服务
- 微服务是一种和SOA相似但本质上不同的架构理念：这种观点认为微服务和SOA只是有点类似，但本质上是不同的架构设计理念。相似点在于下图中交叉的地方，就是两者都关注“服务”，都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有ESB 、服务的粒度、架构设计的目标等。
对比一下SOA和微服务的一些具体做法： - 服务粒度：整体上来说，SOA的服务粒度要粗一些，而微服务的服务粒度要细一些。
例如，对一个大型企业来说，“员工管理系统”就是一个SOA架构中的服务；而如果采用微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管 理”“员工假期管理”“员工福利管理”等更多服务 - 服务通信：SOA采用了ESB作为服务间通信的关键组件，负责服务定义、服务路由 、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful协议、RPC协议，无须 ESB 这样的重量级实现
Martin Flower将微服务架构的服务通信理念称为“ Smart endpoints and dumb pipes简单翻译为“聪明的终端，愚蠢的管道”。 之所以用“愚蠢”二字，其实就是与ESB对比的，因为ESB太强大了，既知道每个服务的协议类型（例如，是RMI还是HTTP），又知道每个服务的数据类型（例如，是XML还是JSON），还知道每个数据的格式（例如，是 2017-01-01还是01/01/2017），而微服务的“ dumb pipes ”仅仅做消息传递，对消息格式和内容一无所知 - 服务交付：SOA对服务的交付并没有特殊要求，因为SOA更多考虑的是兼容己有的系统；微服务的架构理念要求“快速交付”相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践，如果没有这些基础能力支撑，微服务规模一旦变大（例如，超过20个微服务），整体就难以达到快速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的坑，就是系统拆分为微服务后，部署的成本呈指数上升
- 应用场景：SOA更加适合于庞大、复杂、异构的企业级系统，这也是SOA诞生的背景 。这类系统的典型特征就是很多系统已经发展多年，采用不同的企业级技术，有的是内部开发的， 有的是外部购买的，无法完全推倒重来或进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是ESB；微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于Web ，虽然开发技术可能差异很大（例如， Java 、 C＋＋、 .NET 等），但对外接口基本都是提供HTTP RESTful风格的接口，无须考虑在接口层进行类似SOA的ESB那样的处理
综合上述分析 ，我们将 SOA 和微服务对 比如下表所示。
SOA 和微服务是两种不同理念的架构模式，并不存在孰优孰劣，而只是应用场景不同而己
微服务具体有哪些坑
服务划分过细，服务间关系复杂
服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度了，理论上，n个服务的复杂度是n*(n-1)/2整个系统的复杂度是随着微服务数量的增加呈指数级增加的
服务数量太多，团队效率急剧下降
微服务的“微”字，本身就是一个陷阱，很多团队看到“微”字后，就想到必须将服务拆分得很细，有的团队人员规模是5~6个人，然而却拆分出30多个微服务，平均每个人要维护 5 个以上的微服务，这样做给工作效率带来了明显的影响，一个简单的需求开发就需要涉及多个微服务，光是微服务之间的接口就有6～7个，无论设计、开发，还是测试、部署，都需要工程师不停地在不同的服务间切换
- 开发工程师要设计多个接口，打开多个工程，调试时要部署多个程序，提测时打多个包
- 测试工程师要部署多个环境，准备多个微服务的数据，测试多个接口
- 运维工程师每次上线都要操作多个微服务，并且微服务之间可能还有依赖关系
调用链太长，性能下降
由于微服务之间都是通过HTTP或RPC调用的，每次调用必须经过网络。 一般线上的业务接口之间的调用，平均响应时间大约为50ms ，如果用户的一起请求需要经过6次微服务调用，则性能消耗就是300ms ，这在很多高性能业务场景下是难以满足需求的。 为了支撑业务请求，可能需要大幅增加硬件，这就导致了硬件成本的大幅上升
调用链太长，问题定位困难
系统拆分为微服务后，一次用户请求需要多个微服务协同处理，任意微服务的故障都将导致整个业务失败。然而由于微服务数量较多，且故障存在扩散现象，快速定位到底是哪个微服务故障是一件复杂的事情。样例如下图所示：
如果多个微服务同时发生不同类型的故障，则定位故障更加复杂，如下图所示：
没有自动化支撑，无法快速交付
如果没有相应的自动化系统进行支撑，都是靠人工去操作，那么微服务不但达不到快速交付的目的，甚至还不如一个大而全的系统效率高，例如：
- 没有自动化测试支撑，每次测试时需要测试大量接口
- 没有自动化部署支撑，每次部署6～7个服务，几十台机器，运维人员敲shell命令逐台部署，手都要敲麻
- 没有自动化监控，每次故障定位都需要人工查几十台机器几百个微服务的各种状态和各种日志文件
没有服务治理，微服务数量多了后管理混乱
信奉微服务理念的设计人员总是强调微服务的lightweight特性，并举出ESB的反例来证明微服务的优越之处 。但具体实践后就会发现，随着微服务种类和数量越来越多，如果没有服务治理系统进行支撑，微服务提倡的lightweight就会变成问题
- 服务路由：假设某个微服务有60个节点，部署在20台机器上，那么其他依赖的微服务如何知道这个部署情况？
- 服务故障隔离：假设上述例子中的60个节点有5个节点发生故障了，依赖的微服务如何处理这种情况？
- 服务注册和发现：同样是上述的例子，现在我们决定从60个节点扩容到80个节点， 或者将60个节点缩减为40个节点，新增或减少的节点如何让依赖的服务知道？
微服务最佳实践
服务粒度
微服务拆分应基于团队规模进行拆分，通常一个微服务三个人负责开发（三个火枪手原则）,当微服务稳定后一人维护即可
拆分方法
基于业务逻辑拆分
这是最常见的一种拆分方式，将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务。具体拆分的时候，首先根据“ 三个火枪手”的原则计算一下大概的服务数量范围，然后确定合适的“职责范围”，否则就可能出现划分过细的情况
基于可扩展拆分
将系统中的业务模块按照稳定性进行排序，将己经成熟和改动不大的服务拆分为稳定服务，将经常变化和法代的服务拆分为变动服务。稳定的服务粒度可以粗一些，即使逻辑上没有强关联的服务，也可以放在同一个子系统中，例如，将“日志服务”和“升级服务”放在同一个子系统中；不稳定的服务粒度可以细一些，但也不要太细，始终记住要控制服务的总数量，这样拆分主要是为了提升项目快速迭代的效率，避免在开发的时候，不小心影响己有的成熟功能导致线上问题
基于可靠性拆分
将系统中的业务模块按照优先级排序，将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。具体拆分的时候，核心服务可以是一个， 也可以是多个，只要最终的服务数量满足“三个火抢手”的原则就可以
这样拆分带来如下几个好处：
- 避免非核心服务故障影响核心服务，例如，日志上报一般都属于非核心服务，但是在某些场景下可能有大量的日志上报，如 果系统没有拆分，那么日志上报可能导致核心服务故障，拆分后即使日志上报有问题， 也不会影响核心服务
- 核心服务高可用方案可以更简单，核心服务的功能逻辑更加简单，存储的数据可能更少，用到的组件也会更少，设计高可 用方案大部分情况下要比不还分简单得多
- 能够降低高可用成本 ，将核心服务拆分出来后，核心服务占用的机器、带宽等资源比不拆分要少得多，因此， 只针对核心服务做高可用方案，机器、带宽等成本比不拆分要节省较多
基于性能拆分
基于性能拆分和基于可靠性拆分类似，将性能要求高或性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务，常见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等，例如，电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独 立为一个服务
以上几种拆分方式不是只能选一个 ，而是可以根据实际情况自由排列组合。例如，可以基于可靠性拆分出服务A，基于性能拆分出服务B，基于可扩展拆分出C/D/F三个服务，加上原有的服务X，总共最后拆分出6个服务（A/B/C/D/F/X）
基础设施
大部分人主要关注的是微服务的“ small ”和 “ lightweight ”特性， 但实际上真正决定微服务成败的，恰恰是“ automated ”，因为服务粒度即使划分不合理，实际落地后如果团队遇到麻烦，自然会想到拆服务或合服务。如果“ automated ” 相关的基础设施不健全，那补起来可就不是一天两天的事情
微服务基础设施如下图所示：
感觉比ESB还要复杂，确实如此，微服务并不是很多人认为的那样又简单又轻量级。要做好微服务，这些基础设施都是必不可少的，微服务并没有减少复杂度，而只是将复杂度从ESB转移到了基础设施，例如“服务发现”“服务路由”等其实都是ESB的功能，只是在微服务中剥离出来成 了独立的基础系统
每项微服务基础设施都是一个平台、一个系统、一个解决方案，如果要自己实现， 其过程和做业务系统类似，都需要经过需求分析、架构设计、开发、测试、部署上线等步骤
自动化测试
微服务将原本大一统的系统拆分为多个独立运行的“微”服务，微服务之间的接口数量大大增加， 并且微服务提倡快速交付，版本周期短，版本更新频繁，如果每次更新都靠人工回归整个系统，则工作量大，效率低下，达不到“快速交付”的目的，因此必须通过自动化测试系 统来完成绝大部分测试回归的工作
自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测 试，理想情况是每类测试都自动化，如果因为团队规模和人力的原因无法全面覆盖，至少要做到接口测试自动化
自动化部署
相比大一统的系统，微服务需要部署的节点增加了几倍甚至十几倍，微服务部署的频率也会大幅提升，综合计算下来，微服务部署的次数是大一统系统部署次数的几十倍。这么大量的部署操作，如果继续采用 人工手工处理，需要投入大量的人力，且容易出错，因此需要自动化部署的系统来完成部署操作
自动化部署系统包括版本管理、资源管理（例如，机器管理、虚拟机管理）、部署操作、回退操作等功能
配置中心
微服务的节点数量非常多，通过人工登录每台机器手工修改，效率低，容易出错。特别是在部署或排障时，需要快速增删改查配置，人工操作的方式显然是不行的。除此以外， 有的运行期配置需要动态修改并且所有节点即时生效，人工操作是无法做到的 。综合上述的分析，微服务需要一个统一的配置中心来管理所有微服务节点的配置
配置中心包括配置版本管理（例如，同样的微服务，有10个节点是给移动用户服务的，有20个节点给联通用户服务的，配置项都一样， 配置值不一样）、增删改查配置 、节点管理、配置同步、配置推送等功能 。
接口框架
微服务提倡轻量级的通信方式， 一般采用 HTTP/REST 或 RPC 方式统一接口协议。但在实践过程中 ，光统一接口协议还不够，还需要统一接口传递的数据格式
例如，我们需要指定接口协议为HTTP/REST，但这还不够，我们还需要指定HTTP/REST的数据格式采用JSON ，并且JSON的数据都遵循如下规范
{
"requestId":10086,
"time":"2017-01-01 00:00:00",
"caller":"tencent",
"api":"get_money",
"param":{
"userId":15901281919
},
"sign":"314159265358979323846aefaegh"
}
如果我们只是简单指定了HTTP/REST协议，而不指定JSON和JSON的数据规范，那么就会出现这样混乱的情况：有的微服务采用XML，有的采用JSON， 有的采用键值对，即使同样都是JSON, JSON 数据格式也不一样。这样每个微服务都要适配几套甚至几十套接口协议，相当于把曾经由 ESB 做的事情转交给微服务自己做了，这样做的效率显然是无法接受的。因此我们需要统一接口框架
接口框架不是一个可运行的系统，一般以库或包的形式提供给所有微服务调用。例如，针对上面的JSON样例，可以由某个基础技术团队提供多种不同语言的解析包(Java包、 Python包、 C库等)
API 网关
系统拆分为微服务后，内部的微服务之间是互联互通的，相互之间的访问都是点对点的,如果外部系统想调用系统的某个功能，也采取点对点的方式，则外部系统会非常“头大,因为在外部系统看来， 它不需要也没办法理解这么多微服务的职责分工和边界 ，它只会关注它需要的能力，而不会关注这个能力应该由哪个微服务提供
除此之外，外部系统访问系统还涉及安全和权限相关的限制，如果外部系统直接访问某个微服务， 则意味着每个微服务都要自己实现安全和权限的功能，这样做不但工作量大，而且都是重复工作
综合上述分析，微服务需要一个统一的 API 网关，负责外部系统的访问操作,API网关是外部系统访问的接口，所有的外部系统接入系统都需要通过API网关,主要包括接入鉴权（是否允许接入）、权限控制（可以访问哪些功能）、传输加密、请求路由、流量控制等功能
服务发现
微服务种类和数量很多，如果这些信息全部通过手工配置的方式写入各个微服务节点，首先配置工作量很大，配置文件可能要配几百上千行，几十个节点加起来后配置项就是几万几十万行了，人工维护这么大数量的配置项是一项灾难。其次是微服务节点经常变化，可能是由于扩容导致节点增加，也可能是故障处理时隔离掉一部分节点， 还可能是采用灰度升级，先将一部分节点升级到新版本，然后让新老版本同时运行：不管哪种情况，我们都希望节点的变化能够及时同步到所有其他依赖的微服务 。如果采用手工配置，是不可能做到实时更改生效的 。因此，我们需要一套服务发现的系统来支撑微服务的自动注册和发现
服务发现主要有两种实现方式： 自理式和代理式。
【自理式】
自理式结构如下图
自理式结构就是指每个微服务自己完成服务发现。例如，图中SERVICE INSTANCE A访 问 SERVICE REGISTRY获取服务注册信息，然后直接访问SERVICE INSTANCE B
自理式服务发现实现比较简单，因为这部分的功能一般通过统一的程序库或程序包提供给各个微服务调用，而不会每个微服务都自己来重复实现一遍;并且由于每个微服务都承担了服务发现的功能，访问压力分散到了各个微服务节点，性能和可用性上不存在明显的压力和风险
【代理式】
代理式结构如下图所示 。
代理式结构就是指微服务之间有一个负载均衡系统（图中的LOAD BALANCER节点），由负载均衡系统来完成微服务之间的服务发现
代理式的方式看起来更加清晰，微服务本身的实现也简单了很多，但实际上这个方案风险较大
- 第一个风险是可用性风险，一旦LOAD BALANCER系统故障，就会影响所有微服务之间的调用
- 第二个风险是性能风险，所有的微服务之间的调用流量都要经过LOAD BALANCER系统，性能压力会随着微服务数量和流量增加而不断增加，最后成为性能瓶颈,因此LOAD BALANCER系统需要设计成集群的模式，但LOAD BALANCER集群的实现本身又增加了复杂性
不管是自理式还是代理式，服务发现的核心功能就是服务注册表，注册表记录了所有的服务节点的配置和状态，每个微服务启动后都需要将自己的信息注册到服务注册表，然后由微服务或 LOAD BALANCER 系统到服务注册表查询可用服务
服务路由
有了服务发现后，微服务之间能够方便地获取相关配置信息，但具体进行某次调用请求时，我们还需要从所有符合条件的可用微服务节点中挑选出一个具体的节点发起请求，这就是服务路由需要完成的能
服务路由和服务发现紧密相关，服务路由一般不会设计成一个独立运行的系统，通常情况下是和服务发现放在一起实现的。对于自理式服务发现，服务路由是微服务内部实现的；对于代理式服务发现，服务路由是由LOAD BALANCER系统实现的
无论放在哪里实现，服务路由核心的功能就是路由算法。常见的路由算法有 ： 随机路由、轮询路由、最小压力路由、最小 连接数路由等算法。
服务容错
系统拆分为微服务后，单个微服务故障的概率变小，故障影响范围也减少，但是微服务的节点数量大大增加。从整体上来看，系统中某个微服务出故障的概率会大大增加。前面我们分析微服务陷阱时提到微服务具有故障扩散的特点，如果不及时处理故障，故障扩散开来就会导 致看起来系统中很多服务节点都故障了
因此需要微服务能够自动应对这种出错场景，及时进行处理。否则如果节点一故障就需要人工处理，投入人力大，处理速度慢。而一旦处理速度慢，则故障就很快扩散，所以我们需要服务容错的能力
常见的服务容错包括请求重试、流控和服务隔离
【请求重试】
请求重放和请求重试类似，不同点在于：请求重试是向同一个微服务节点重新发送请求；请求重放是向不同的微服务节点重新发送请求，通常情况下，请求重试由微服务节点或代理节点实现
【流控】
当出现异常情况，导致某个或某类微服务的请求数量突增或爆发，由于系统容量限制 ，无法快速应对突发容量，导致整个微服务响应都变慢甚至完全瘫痪，此时需要将一部分流量拒绝，从而保证大部分流量的请求正常。这就是流控需要实现的功能 。
通常情况下，流控由各个微服务节点自己实现，可以将流控策略包装成公共库提供给各个 微服务使用，减少重复实现。
【服务隔离】
由于微服务几乎都是集群部署，因此当某个微服务节点故障时，最快最简单的处理方式就是直接将当前故障节点下线隔离，避免故障进行扩散。这就是服务隔离需要实现的功能。 通常情况下，服务隔离分为主动隔离、被动隔离和手动隔离
- 主动隔离指微服务节点自己判断自己异常后，主动从服务发现系统中注销
- 被动隔离指服务发现系统根据设定的规则（连接状态、响应时间、错误率等）判断微服务节点故障后，将其从服务发现系统中注销
- 手动隔离指人工判断系统故障后，通过手工操作将其从服务发现系统中注销
主动隔离和被动隔离响应及时，能够快速隔离故障，缺点就是实现起来比较复杂，需要根据线上的各种复杂情况制定规则；手动隔离虽然响应没有那么及时，但实现起来很简单。实际应用场景中，一般都是结合起来使用：实现基于简单策略的主动隔离和被动隔离，更复杂的情况由人工去隔离
服务监控
系统拆分为微服务后，节点数量大大增加，导致需要监控的机器、网络、进程、接口调用数等监控对象的数量大大增加；同时，一旦发生故障，我们需要快速根据各类信息来定位故障 。
服务监控作用
- 实时搜集信息并进行分析，避免故障后再来分析，减少了处理时间
- 服务监控可以在实时分析的基础上进行预瞥 ，在问题萌芽的阶段发觉并预警 ，降低了问题影响的范围和时间
通常情况下，服务监控需要搜集并分析大量的数据，因此建议做成独立的系统，而不要集成到服务发现、 API 网关等系统中
服务跟踪
服务监控可以做到微服务节点级的监控和信息收集，但如果我们需要跟踪某一个请求在微服务中的完整路径，服务监控是难以实现的。因为如果每个服务的完整请求链信息都实时发送给服务监控系统，数据量会大到无法处理
服务监控和服务跟踪的区别可以简单概括为宏观和微观的区别 。 例如，A服务通过HTTP协议请求B服务 10次，B通过HTTP返回JSON对象，服务监控会记录请求次数、响应时间平均值、响应时间最高值、错误码分布这些信息；而服务跟踪会记录其中某次请求的发起时间、响应时间、响应错误码、请求参数、返回的 JSON 对象等信息
目前无论分布式跟踪，还是微服务的服务跟踪，绝大部分请求跟踪的实现技术都基于 Google的 Dapper 论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure 》
服务跟踪关键技术
-
标注点
标注点又叫植入点或埋点，通过在应用程序或中间件中明确定义一个全局的标注(annotation），它可以是一个特殊的ID ，通过这个ID连接每一条记录和发起者的请求，然后跟踪系统再根据这个ID将整个业务请求链串联起来
由于全局标注点需要在所有经过的服务节点中进行处理，因此需要代码植入。在生产环境中，如果所有的应用程序都使用相同的线程模型、控制流和 RPC 系统，则可以把代码植入限制在一个很小的通用组件库中，从而达到监测系统应用对开发人员的透明 -
跟踪树和span
分布式跟踪通过跟踪树来表示一个完整的跟踪流程，其中某个服务从接到请求到返回响应这个时间跨度范围被称为span，一个span内，服务本身又会发起多次到其他服务的调用
跟踪树结构中，树节点是整个架构的基本单元，而每一个节点又是对span的引用。节点之间的连线表示的span和它的父span的直接关系。通过简单的parentld和spanId就可以有序地把所有的关系串联起来达到记录业务流的作用
服务跟踪目的
- 采样跟踪
根据一定的概率对请求进行采样跟踪，然后基于采样数据进行分析（例如，谷歌的 Dapper 系统），可以被用于发现系统问题，但它更通常用于探查性能不足，以及提高全面大规模的工作负载下的系统行为的理解。这种方式主要的优势是无须跟踪所有的请求，性能消耗和对系统的压力会小得多 - 染色跟踪
线上环境有时会出比较诡异的问题，即同样功能或业务，大多数用户都没有问题，很少一部分用户会出错。单纯从代码逻辑或系统日志来看是找不到问题原因的，此时需要针对单个用户的特定请求进行全链路跟踪，这就是通常所说的染色跟踪
微服务中的染色跟踪原理，我 们将想要跟踪的用户“染色”（其实就是在请求入口处打上标记），每个微服务看到有标记的请求就进行跟踪，最后汇总跟踪信息就可以看出整个业务请求的所有细节
服务安全
系统拆分为微服务后，数据分散在各个微服务节点上。从系统连接的角度来说，任意微服务都可以访问所有其他微服务节点；但从业务的角度来说 ，部分敏感数据或操作只能部分微服务可以访问，而不是所有的微服务都可以访问。因此需要设计服务安全机制来保证业务和数据的安全性
例如，假设我们有一个“用户信息管理”微服务，其中包含所有用户的基本信息（姓名、 性别、职位、身份证、手机号码等〉 ， “用户信息管理”对外提供“增删改查”用户信息的接口。 针对“用户信息管理”微服务，我们需要设计如下安全相关的策略：
- 所有其他微服务都可以读取用户的姓名、性别、职位信息；
- 部分微服务可以读取用户的身份证和手机号码信息 ；
- 只有“人力资源管理”微服务可以修改和删除用户信息。
服务安全主要分为三部分
- 接入安全:接入安全指只有经过允许，某个微服务才能访问另外一个微服务，否则被访问的微服务 会直接拒绝服务
- 数据安全:数据安全指某些数据相关的操作只 允许授权的微服务进行访问， 否则被访问的微服务会 拒绝数据操作
- 传输安全:传输安全指某些敏感数据在传输过程中需要进行防窃取 、防篡改处理 ，以保证数据的真 实性和有效性
通常情况下，服务安全可以集成到配置中心系统中进行实现，即配置中心配置微服务的接入安全策略和数据安全策略，微服务节点从配置中心获取这些配置信息，然后在处理具体的微服务调用请求时根据安全策略进行处理 。 由于这些策略是通用的， 一般会把策略封装成通用的库提供给各个微服务调用。
基本架构如下图所示:
