类似Google Dapper，为微服务打造分布式跟踪工具

最新推荐文章于 2023-01-16 10:55:34 发布

weixin_34408624

最新推荐文章于 2023-01-16 10:55:34 发布

阅读量162

点赞数

文章标签： python 系统架构后端

原文链接：https://my.oschina.net/jimilee/blog/733163

版权

2019独角兽企业重金招聘Python工程师标准>>>

概述

作为工程师，我们总是喜欢让事情变得简单化、自动化。其实仔细去想，面向过程编程就是这种思维的产物之一，再到后来，我们发明了面向对象编程。不管是哪种编程模式，这些概念永远都有着核心的共同点：把一些大的东西折分成小的、独立的模块，再开放或者共用抽象层，隐藏实现层的细节。

抽象化

抽象能够帮助我们更好的理解大型的、复杂的系统，同时编写独立的模块也更有效率。我们进行系统架构设计的方式也在不断地革新：

客户端-服务端 N层架构
SOA 面向服务编程
微服务架构

分而治之

如果你去分享，不难发现，这些实现方式都包含的相同的架构思想和理念，这也是为什么聊聊架构一直在推崇先去理解架构的道，再去看架构图的原因之一。

把系统解耦成更小的单元
**单一职责原则（SRP）：**每个单元都有自己的职责 —— 做好一件事情
**开放封闭原则（OCP）：**每个单元通过API暴露，外界不需要关心它的具体实现
** 应用隔离原则（ASP）：**所有的单元都是独立的，可以独立的进行开发、部署、扩展、以及监控
**依赖反转原则（DIP）：**各个单元之间可以通过RPC请求进行交互

我们可以通过不断的添加新的、小的模块或者重用已经有的模块来构建复杂的系统。我们通过构建模块，然后通过这些模块来构建任何我们想要的东西。就像“乐高”一样，在合适的地方添加你想要的东西。

当然我们必须要保持平衡，对于微服务架构而言也没有例外。系统的耦合度越低，我们能控制的就越少。最后我们可能就只知道我们有一个很酷的基础架构下面有很多的微服务互相交互，有时候可能都看不到一个整体的、全局的视野。

微服务的世界

输入图片说明

这是一个典型的微服务架构，我们可以看到6个微服务和一些依赖项（可能一些RPC的调用）。同时，在一段时间的尝试和研究之后，我们发现了一些可用的基础架构型模式：微服务路由（micro-service routes）。

输入图片说明

所以我们看到了3个微服务路由：

新用户注册——由微服务A，B，C，和E实现
下订单——由微服务A，B，C，和D实现
支付——由微服务A，B，C，D和F实现

如你所见：

有一些服务相对来说更重要、常用（A，B，C和D）
有一些服务几乎不怎么被使用（E和F）
常用的服务对于某些服务路由来说可能会造成瓶颈（C和D）

想象一下这样的一个场景：某一天突然你的“支付流程”变慢了，事出必有因。你需要收集那些比平台慢3倍的支付请求记录，来找到是什么地方、原因导致的。同时，如果是由于某些特殊的场景导致的，怎么办？

比如说，只有澳大利亚的部分客户，他们的收件箱里面有未读消息，导致他们在支付的时候只有30%的情况下是成功的。你在丢失利润的同时，也有可能丢失忠诚的用户。你知道“支付”路由包含了A，B，C，D和F微服务，但是却完全不知道到底发生了什么？这种事情时有发生，如恶梦般，对吗？

在一些常见的软件里面，我们有一些工作可以帮助我们很容易的找到问题，比如debugger和profiler。这是单体应用程序的好处，一切都是运行在同一个进程里面。但是一旦我们的程序使用了RPC请求之类的玩意儿，我们在这些超级酷的工具APM/debugger/profler等工具下面将只会看到这样的信息：“外部请求XYZ超时16.5秒…” 这还真的是挺慢的，但是我们仅仅发现了一个瓶颈。

不要太快

这会帮助你发现你的App正在经历的一些延迟问题吗？答案是“Yes”。这会帮助你修复问题让你的App恢复快速的网络访问吗？答案是“No”。如果那个XYZ服务又调用了其它三个服务怎么办？如果后面三个服务同样的也有其它服务的请求呢？如果你有20+个微服务在用不同的方式互相调用，怎么办？

这就是现如今，当我们把业务解耦成小的、独立的、分布式的、通过网络访问的单元（也就是微服务）之后的世界。欢迎来到这个你看不到任何东西的世界！

所以我们需要从全局、整体层面去看我们的系统：