浅谈微服务

微服务已经火了很久了，很多人对这个东西感觉很高大上，实际上，有点规模的互联网公已经把微服务用的很顺手了，说实话，这门技术的使用，完全是“被迫”接受的。

一、该不该去学微服务

大多数开发者都希望能接触到微服务开发，然而并不是每家公司都愿意花这么大的成本去搞这个东西，环境所逼，很多人为了自己的前途，拼命想去大厂，大公司有什么好处呢，我随便列举几点：

• 1.工资福利待遇较好
• 2.技术栈先进，成熟的、规范化的开发流程
• 3 . 较为成熟的晋升渠道

很多人会说，学了不能用的技术学了也没用啊，在工作中学习能用到的技术才是最有效的，我以前也是这么听别人讲的，现在想起来，纯粹放屁，互联网这个行业，人员流动性是很高的，大家都想一步步晋级去大厂，很多知识，是大厂需求的，但是在一般的小公司，毫无用武之地。别人跟你说，你别学这个了，我们公司用不到的，你学了也是白学，现在用不到就不学了？搞怪吧，我现在学的东西难道不是为未来的我做准备的，而是单纯为这家公司做准备的？我用一个打工者的角度来思考这个问题（一些领导或者资本家的角度大多是有自我利益性的，都是基于自己利益不被损害的前提下来做事），毕竟大多数人都是打工者，学以致用当然是好，但是大多数人并不是有这样的机会，没有这个机会怎么办，自己去创造啊，我想搞微服务，现在这家不搞，那你以后就去找一家有搞的啊，学习干嘛还要找这么多的借口。对于后端开发来说，我觉得要有追求，还是要对微服务有点了解。我相信努力的你，未来一定会用到它。

二、微服务是什么

定义：微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理 （例如 Docker）技术，服务可以用不同的编程语言与数据库等

博主也去过一些公司，接触到的技术团队也不算少了，有十几人的，也有几十人，几百人的。我发现，微服务这个东西，只有对技术有追求的公司，规模稍微大些的才会弄。这些公司受不住大单体项目的摧残，他们是没办法的，规模到那个程度了，不搞微服务得不偿失，当项目复杂性达到一定的量级，开发人员也到达了一定的人数，微服务拆分便是必然的趋势。

微服务是趋向后端的概念，微服务的核心在于这个“微”字，以前的时候，我们经常把一个项目写在一个仓库中，所有跟这个项目有关的内容全部放在一起。大家开发共用一个仓库，如果没有人强制设立规范的话，代码质量和目录规范什么的都无法达到保证，随着项目的扩大以及开发人员的增加，风险也会随之增大，有可能一人为了开发A功能，导致其他功能都挂了，或者说有人改动了一小段共用代码，导致其他子系统奔溃。当然，这都是有可能的。

慢慢的大家觉得，有些东西可以单独抽离处理作为一个独立的模块（服务），在开发，测试，部署的过程中都可以单独对其操作。模块之间的上线发布互不影响。代码仓库相互隔离。例如，评论模块和点赞模块拆分成两个微服务，点赞服务挂了，评论模块还是正常不受影响的，对用户来说，只是局部性功能失效，用户体验也不会太差。

三、微服务和单体应用的优劣势

技术一直是双刃剑，有优势必然也会有劣势，毕竟软件设计没有银弹。

微服务优势：

• 服务独立部署维护
• 服务性能提升
• 业务拆分更细，各司其职
• 代码维护更简单，单个服务业务复杂性低

微服务劣势：

• 运维成本高
• 对开发者的要求更高
• 前期投入成本大

单体架构优势：

• 开发快速
• 部署简单，对开发者要求较低
• 运维成本低

单体架构劣势：

• 容易发生级联事故
• 系统高可用查
• 线上发布慢
• 团队协作开发成本高（人员规模大时）

单体架构适合项目刚开始需要快速迭代上线，技术人员人员较少的场景，但是随着系统的复杂性逐渐增加，单体所带来的的劣势远比优势更加突出，此时，在公司实力的允许下，单体必将被微服务所重构。

四、微服务架构包括哪些内容

开始干货内容

1. 微服务拆分

1.1 纵向拆分（业务拆分）

按业务维度进行拆分，标准是按照业务的关联程度来决定，关联比较密切的业务拆分为一个微服务， 而功能相对比较独立的业务适合单独拆分为一个微服务

1.2 横向拆分（功能拆分）

按公共且独立功能维度拆分，标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不与其他业务耦合

一般来说，有以上两种方式的拆分维度，具体的拆分选择需要按照公司业务以及人员规模进行决定

2. 微服务发布和引用

常常有以下三种服务实现方式

• resfulApi
• xml配置
• IDL文件（grpc/thrift)

3.服务注册（注册中心）

基于RPC实现的微服务，常用存在三种角色，分别是

• 服务提供者
• 服务消费者
• 服务注册中心
  
  其中注册中心充当着服务提供者和服务消费者之间的中介介绍所角色
  服务调用者，想要知道服务提供者的调用信息，则需要向中介介绍所获取信息。这就好比是商家，平台，用户三者的关系。商家在平台上注册自己的信息，用户通过平台获取商家的信息，再和商家进行联系

注册中心是整个微服务中较为复杂的部分。一个注册中心往往需要提供一系列 API 供服务调用者和服务提供者使用。一般至少需要以下的接口：

• 服务注册接口（用于服务的注册）
• 服务反注册接口（用于服务的注销）
• 心跳汇报接口（检测服务是否可用）
• 服务订阅接口（订阅服务，服务有变动时会有消息推送）
• 服务查询接口（查询服务信息）
• 服务变更查询接口（查看服务的变更信息）
• 服务修改接口（修改服务注册信息）

为了避免中介所挂壁，导致两端无法正常通信，往往注册中心会采用集群的部署方式，这就意味着对于节点之间的数据同步有着很大的挑战。

4. 微服务调用

微服务的调用可分为三步曲：

4.1 建立连接

建立连接一般有两种方式，一种是基于应用层的HTTP通信，一种是底层的socket通信。

4.2 数据传输

数据传输方式有基于HTTP和grpc的实现，通过为了高性能以及减少网络带宽，我们会使用pb对象的方式进行传输，而不是使用可视化较好的 json 格式进行传输，比较 pb 是二进制的传输方式。性能相对较好。

4.3 服务端处理请求

服务端处理一般有三种处理机制，分别为

• 同步阻塞方式（BIO)
  客户端每发一次请求，服务端就生成一个线程去处理。当客户端同时发起的请求很多时，服务端需要创建很多的线程去处理每一个请求，如果达到了系统最大的线程数瓶颈，新来的请求就没法处理了
• 同步非阻塞方式（NIO)
  客户端每发一次请求，服务端并不是每次都创建一个新线程来处理，而是通过 I/O 多路复用技术进行处理。就是把多个 I/O 的阻塞复用到同一个 select 的阻塞上，从而使系统在单线程的情况下可以同时处理多个客户端请求。这种方式的优势是开销小，不用为每个请求创建一个线程，可以节省系统开销。
• 异步非阻塞方式（AIO)
  客户端只需要发起一个 I/O 操作然后立即返回，等 I/O 操作真正完成以后，客户端会得到 I/O 操作完成的通知，此时客户端只需要对数据进行处理就好了，不需要进行实际的 I/O 读写操作，因为真正的 I/O 读取或者写入操作已经由内核完成了。这种方式的优势是客户端无需等待，不存在阻塞等待问题。

几种处理方式各有好处和劣势，因此一般根据 业务进行决定，但是市面上常用的RPC框架已经帮我们把这个搞好了，不需要我们对其关心。

5. 微服务监控

5.1 监控对象：

• 用户端的监控： 通常是指业务直接对用户提供的功能的监控
• 接口监控：通常是指业务提供的功能所依赖的具体 RPC 接口的监控
• 资源监控：通常是指某个接口依赖的资源的监控
• 基础监控：通常是指对服务器本身的健康状况的监控

5.2 监控指标

• 请求量：实时请求量（QPS) 和统计请求量（PV)
• 响应时间：服务在不同时间段的响应时间
• 错误率：错误率的监控通常用一段时间内调用失败的次数占调用总次数的比率来衡量

5.3 监控维度

• 全局维度
• 分机房维度
• 单机维度
• 时间维度
• 核心维度

不同的监控维度往往是业务需要，导致监控的侧重点不同。

6. 微服务追踪

6.1 作用

基于RPC的调用方式，和本地服务器调用有着很大的不同，涉及不同服务器，不同网络，不同物理区域。因此为了能准确定位调用链路中的问题，需要微服务的追踪。当然作用不当当只有问题定位，还有很多，例如：

• 优化系统瓶颈： 通过记录调用经过的每一条链路的耗时
• 优化链路调用：分析调用经过的路径，优化调用
• 生成网络拓扑：生成一张系统的网络调用拓扑图，它可以反映系统都依赖了哪些服务，以及服务之间的调用关系是什么样的
• 透明传输数据：逐层传递同一数据

6.2 原理

一般有三种实现方式：

• traceId：用于标识某一次具体的请求 ID。当用户的请求进入系统后，会在 RPC 调用网络的第一层生成一个全局唯一的 traceId，并且会随着每一层的 RPC 调用，不断往后传递，这样的话通过 traceId 就可以把一次用户请求在系统中调用的路径串联起来

• spanId：用于标识一次 RPC 调用在分布式请求中的位置。当用户的请求进入系统后，处在 RPC 调用网络的第一层 A 时 spanId 初始值是 0，进入下一层 RPC 调用 B 的时候 spanId 是 0.1，继续进入下一层 RPC 调用 C 时 spanId 是 0.1.1，而与 B 处在同一层的 RPC 调用 E 的 spanId 是 0.2，这样的话通过 spanId 就可以定位某一次 RPC 请求在系统调用中所处的位置，以及它的上下游依赖分别是谁

• annotation： 用于业务自定义埋点数据，可以是业务感兴趣的想上传到后端的数据，比如一次请求的用户 UID

6.3 实现逻辑

• 数据采集
  – CS阶段（client send）：客户端发起请求，并生成调用的上下文
  – SR阶段（server receive）：服务端接受请求，并生成上下文
  – SS阶段（server send）：服务端返回请求，这个阶段会将服务端上下文数据上报
  – CR阶段（client receive）：客户端接收返回结果，这个阶段会将客户端上下文数据上报

• 数据处理
  数据处理一般有两种范式，一种是实时数据处理，一种是离线数据处理。通过是两种方式相结合实现。

• 数据展示
  一般以调用链路图和调用拓扑图进行呈现

7. 微服务治理

• 节点管理
  包括注册中心主动摘除机制和服务消费者主动拆除机制

• 负载均衡
  – 随机算法
  – 轮训算法
  – 最少活跃调用法
  – 一致性hash算法

• 服务路由
  可分为静态配置和动态配置，大家可以类比静态路由和静态路由

• 服务容错
  包含四种容错机制
  – FailOver：失败自动切换
  – FailBack：失败通知
  – FailCache：失败缓存
  – FailFast：快速失败

以上为微服务所涉及到基本知识点，因为篇幅有限，需要继续学习的同学可以自行去研究学习。另外附上博主学习微服务时做的思维导图笔记供大家参考：

需要高清大图的可以在资源里进行下载。