共计 2557 个字符，预计需要花费 7 分钟才能阅读完成。
这篇文章主要介绍“让生产环境微服务更流畅的方式有哪些”，在日常操作中，相信很多人在让生产环境微服务更流畅的方式有哪些问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”让生产环境微服务更流畅的方式有哪些”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
微服务的另一面
关注点分离并不是什么新概念，分布式计算也不是。优势很明显，但是它们的代价通常是时间和金钱上更高的运维成本。将这两者混合在一起，就会遇到所有类型的问题。将其上生产环境，问题会变成四倍。调试修复，但是等一下——
调试并不能让问题消失。
就像 Bryan Cantrill 在其 QCon 演讲里所指出的，“调试已经退化成了口头传说，期望问题能够神话般消失。”事实上，调试更像一门科学，要理解系统是如何工作的，而不是我们认为它是如何工作的。
调试不仅仅是微不足道的边缘任务，而是个根本性问题。Sir Maurice Wilkes，创造出首批程序之一的调试者，那时候就已经认识到调试会成为开发人员需要承担的主要职责。
“在开始编程的 1949 年，我们惊讶地发现让程序像我们认为地那样工作并不容易。必须找到调试方法。我还能记得那一刻，我意识到从今之后我生命的很大一部分会花在寻找自己编写的程序的错误上。”
我们曾经认为这是为了解决问题。但是实际挑战是要理解系统到底是如何工作的。
问题 #1：如果监控单体应用还不够困难
无论你是逐步将单体应用分解成微服务，还是从头构建一个新系统，现在你都有更多的服务需要监控。每个都很有可能：
使用不同的技术 / 语言
在不同机器 / 容器里
有自己的版本
要点是智慧地监控，系统是高度碎片化的，迫切需要中央化监控和日志，才能够理解到底发生了什么事情。
比如，在最近持续讨论播客描述的一个场景里是需要回滚的差版本。这是单体应用最直接的方式。但是——现在我们有微服务了。因此需要确定哪个服务需要回滚，这样的回滚对其他服务会有什么影响，或者可能只是需要添加一些功能，但是也可能就直接将问题推到另一个服务里。
要点 #1：如果你认为监控单体架构很难，那么微服务会更难 10 倍，并且需要预先计划更多的投资。
问题 #2：日志分布在服务间
日志 日志 日志。服务器每天都会产生数 GB 的非结构化文本。IT 界和二氧化碳排放等价的东西，是溢出的硬盘和疯狂的 Splunk 账单 /ELK 存储费用。另外，如果想学习 Splunk 或者 ELK，可以看看我们最新的电子书：《Splunk vs ELK：日志管理工具决策指导》。
在单体架构下，日志很可能已经分散在不同的地方，单体思维里就得使用日志记录在不同地方的几层设计。在微服务里 – 日志更加分散。现在当研究一些用户事务相关的场景时，不得不从所有可能使用到的服务那里将所有的不同日志收集到一起，才能理解什么地方出错了。
在 Takipi 里，我们的团队通过使用 Takipi 解决这样的问题。对于来自生产 JVM 里的所有日志错误或者报警，我们在日志里注入了可以指引事件分析的链接。包括每一帧完整的 stack trace 和变量状态，即使它们分布在一定数量的服务 / 机器上。
要点 #2：微服务是指将东西分解成单个组件。这么做的副作用是，运维和监控也随之分解到每个服务里，并且失去了作为整体的系统的力量。这里的挑战是使用合适的工具重新将这些中央化。
问题 #3：一个服务导致的问题，会造成其他地方的问题
如果跟踪某个特定服务的故障事务，你无法保证正在查看的服务就是出问题的地方。假定服务间有一些消息传递机制，比如 RabbitMQ、ActiveMQ 或者可能使用的是 Akka。
即使服务行为正常，没有找到什么问题，也可能会发生如下场景：
它接收到的输入是错的，那么你需要理解是什么导致前一个服务的异常行为
其结果的接收方返回了一些异常响应，那么你需要理解下一个服务是如何工作的
如果这些依赖条件比 1:1 更加复杂会如何？或者多个服务受益于该问题呢？
无论问题是什么，微服务下的第一步都是要知道从哪里开始寻找答案。数据完全分散，很有可能完全不在日志和仪表盘里。
要点 #3：单体应用里，你通常能够知道检查的方向是正确的，微服务让理解问题的来源在哪里，以及应该到哪里得到数据变得更加困难。
问题 #4：找到问题的根本原因
好的，让我们继续调查。现在的出发点是我们已经找到了有问题的服务，拿到了需要的数据，从日志里找到了 stack trace 和一些变量值。如果使用的是 APM（就像 New Relic、AppDynamics 或者 Dynatrace，我们也有文章介绍，在这里和这里），你可能还得到其他一些数据，有关一些方法的高速处理时间 / 对问题的严重性做了一些基本的评估。
但是——实际问题是什么呢？真正的根本原因？要找到实际出错的代码。
大多数情况下，从日志里首先得到的变量数据并不是真正需要的数据。它们通常指到下一个线索，要求你发现更多的真相，并且添加更多的日志声明。部署变更，期望问题能够重现，或者不重现，因为——有时候仅仅添加一条日志声明似乎就能解决问题。
要点 #4：当某个微服务的根本原因影响多个服务时，有可用的中央化根本原因检测工具至关重要。如果你使用 Java/ 其他 JVM 语言，一定要来看看我们 Takipi 是怎么做的。
Takipi 的错误分析仪表盘——每一帧的变量值放在实际代码之上
问题 #5：版本管理和服务间的循环依赖
持续讨论博客里提到的另一个问题是从典型单体架构的单层模型到微服务的图模型。
这里可能发生的两个问题和依赖有关。
如果在服务间存在循环依赖，当某个事务可能死锁在循环里时，就会出现溢出错误。
如果两个服务共享某个依赖，并且你以会影响它们的方式更新了其他服务的 API，那么就需要一次更新所有这三个服务。这会带来这样的问题，你应该先更新哪个？怎么才能让这样的更新平稳过渡？
更多的服务意味着每个服务都有不同的发布周期，大大增加了这里的复杂度。当问题在一个版本消失，在新版本又出现时，重现问题就会很复杂。
要点 #5：在微服务架构里，你更容易遇到依赖相关的问题。
到此，关于“让生产环境微服务更流畅的方式有哪些”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
