听说你想了解微服务架构

前言： 热辣滚烫的微服务一直在拨撩着程序员的心，然而很多人对微服务架构不甚明了，单纯的为了用而用。只是把现有的单体拆点东西出来，例如商品服务，然后彼此间用上RPC就算微服务了。恕我直言，其实这还相差甚远！

阅读本文你将收获：

1. 了解什么是微服务架构。
2. 了解微服务架构有哪些内容。
3. 了解微服务架构中遇到的问题。
4. 这些问题的解决方案

大纲：

1. 什么是微服务？
2. 微服务架构是什么？
3. 微服务架构的各个组成怎么解决问题的？

一、什么是微服务?

1.1 在谈论什么是微服务的时候，我们先说说为什么需要微服务？

单体之痛：

• 团队开发协作巨麻烦
  多人协同开发的时候，会因为同时修改了代码导致编译不通过，各种重来。

• 系统可用性差
  因为某个同学代码质量问题，成为整个系统的瓶颈所在，影响整个系统的可用性。

• 部署效率低下
  代码越来越多，所涉及的相关资源也越来越多，打包编译一次的时间都能撩个妹了。

• 难以扩展
  当系统需要伸缩的时候，必须对应用程序进行扩容，不能做到对某个功能点单独扩容。

• 我要用微服务
  当你想用微服务的时候，单体的问题你能找出千千万。但是，如果你一定要用，请先通读此文后，做到心中有B-tree了在用！

1.2 微服务解决了什么问题？

当然，微服务能解决上述单体应用出现的问题，不然我写这么多干啥呢~o(￣︶￣)o（手动狗头）

1.3 微服务带来了哪些问题？

任何事情都有两面性，微服务有其优点，必然有其缺点。只有充分了解了其优缺点，结合自身业务和开发能力的实际情况，再来做出权衡取舍，用不用微服务！

微服务的缺点：

• 需要点亮devops技能
  硬实力！

• 分布式系统带来的复杂度几何级上升
  硬实力！

• 对开发人员素质要求变高了
  不再是CRUD就能安安稳稳过日子了

1.4 什么是微服务

维基百科对微服务的定义:

微服务(Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

是的，你没看错，这就完了~

二、微服务架构是什么？

看图说话：

微服务架构的六大组成部分：

1. 服务描述
   解决了如下问题：

   • 对外提供一个服务，那么这个服务的服务名叫什么？
   • 调用这个服务需要哪些信息？
   • 调用这个服务返回的是什么格式？
   • 该如何解析？

2. 注册中心
   有了服务接口的描述，下一步要解决的问题就是服务发布和订阅。

   • 服务发布：服务提供者将自己提供的服务以及地址登记到注册中心。
   • 服务订阅：服务消费者则从注册中心查询所需要调用的服务地址，然后发起请求

3. 服务框架
   解决了如下问题：

   • 服务通信采用什么协议？
   • 数据传输采用什么方式？
   • 数据压缩采用什么格式？

4. 服务监控
   一旦服务提供者和服务消费者能够正常发起服务调用，需要对调用情况进行监控，以了解服务是否正常。

5. 服务追踪
   除了对服务调用情况进行监控之外，需要记录服务调用经过的每一层链路，以便问题追踪和故障定位。

6. 服务治理
   服务监控能够发现问题，服务追踪能够定位问题，解决问题就靠服务治理！

三、微服务架构的各个组成怎么解决问题的？

1. 服务描述

常用的服务描述方式：
- RESTful API： 常用于HTTP协议的服务描述
- XML配置：多用作RPC服务的协议描述
- IDL文件：通常用作Thirft和gRPC这类跨语言服务框架中。

2. 注册中心

注册中心的工作流程：
- 服务提供者在启动时，根据服务发布文件中配置的发布信息向注册中心注册自己的服务。
- 服务消费者在启动时，根据消费者配置文件中的配置信息向注册中心订阅自己所需要的服务。
- 注册中心返回服务提供者地址列表给服务消费者。
- 当服务提供者发生变化，比如节点新增或销毁，注册中心将变更通知给服务消费者。

3. 服务框架

服务通信协议：

• 四层TCP/UDP协议
• 七层HTTP协议

数据传输方式：

• 同步
• 异步
• 单连接上传输
• 多路复用

数据压缩格式：

• JSON序列化
• JAVA对象序列化
• Protobuf序列化

4. 服务监控

要了解服务监控首先要明白有哪些监控对象？具体监控哪些指标？从哪些维度监控？

这个话题有点大，在我做的思维导图里面有详细的概述，希望读者朋友能够结合思维导图一起看！

5. 服务追踪

• 服务消费者发起调用前，会在本地按照一定的规则生成一个requestid，发起调用时，将requestid当做请求参数的一部分，传递给服务提供者。
• 服务提供者收到请求后，记录下本次的requestid，然后处理请求。
• 如果服务提供者继续请求其他服务，会在本地生成一个requestid，然后把这两个requestid当做参数继续往下传递。

6. 服务治理

服务治理就是通过一系列手段保证在各种意外的情况下，服务调用能够正常进行。可分为：

• 单机故障
• 单IDC故障
• 依赖服务不可用

终极杀器

思维导图：

总结：

本文大部分成果总结于极客时间-《从0开始学微服务》胡忠想老师的专栏。一文只是简述阿忠伯的课程，其精华难以概括，有兴趣的同学可以上极客时间订阅该课程！

https://github.com/FristResponder/MindMapping.git

上面是本人学习总结的所有思维导图，喜欢的麻烦给个star​

来源：CSDN

作者：奔奔奔跑

链接：https://blog.csdn.net/firstresponder/article/details/104136336