文档章节

让生产环境微服务更流畅的5种方式

有容云
 有容云
发布于 2016/12/07 10:37
字数 2318
阅读 23
收藏 1

微服务的黑暗面:什么可能会出错?


似乎最近所有人都开始研究微服务,而单体架构一夜之间被抛弃了。



获得的公众关注的某种趋势通常会被夸大,并且并不会反应实际使用中的问题,但是这一次似乎更是一种共识。微服务遵守基本的关注点分离的原则,同时由解决实际问题的工程师团队为服务命名。



本文我们会提出质疑,分享一些社区和我们用户的声音,探讨生产环境里微服务的首要问题——以及可以如何解决这些问题。

 

微服务的另一面

关注点分离并不是什么新概念,分布式计算也不是。优势很明显,但是它们的代价通常是时间和金钱上更高的运维成本。将这两者混合在一起,就会遇到所有类型的问题。将其上生产环境,问题会变成四倍。调试修复,但是等一下——

调试并不能让问题消失。



就像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:版本管理和服务间的循环依赖

持续讨论博客里提到的另一个问题是从典型单体架构的单层模型到微服务的图模型。
 

这里可能发生的两个问题和依赖有关。

  1. 如果在服务间存在循环依赖,当某个事务可能死锁在循环里时,就会出现溢出错误。
  2. 如果两个服务共享某个依赖,并且你以会影响它们的方式更新了其他服务的API,那么就需要一次更新所有这三个服务。这会带来这样的问题,你应该先更新哪个?怎么才能让这样的更新平稳过渡?


更多的服务意味着每个服务都有不同的发布周期,大大增加了这里的复杂度。当问题在一个版本消失,在新版本又出现时,重现问题就会很复杂。

 

要点#5:在微服务架构里,你更容易遇到依赖相关的问题。

 

最后的思考

立刻调试让你希望解决问题,这和调试这个词的直接意思是一致的。当在系统上下文中思考这些时,这里的内容比临时的问题解决要多得多。这有关于当做整体理解系统,系统如何工作,以及实际上是如何的,而不是你希望它如何。

最后,这完全取决于你使用的工具以及工作流。这是我们在构建Takipi所思考的,解决这些实际问题,以及调优应用程序日志来理解生产应用程序的实际状态。

 

来源:http://www.youruncloud.com/docker/1_79.html

本文转载自:http://www.youruncloud.com/docker/1_79.html

有容云
粉丝 2
博文 52
码字总数 38431
作品 0
深圳
私信 提问
微服务是坑?有这些特点的公司适合部署

  【IT168 评论】最近微服务架构非常流行,微服务是一种软件架构模式,它将单片应用程序分解成更小的单用途服务,这些服务独立构建和管理。微服务的优势包括:   ・质量:服务分离可最大...

it168网站
2017/05/22
0
0
干货下载:谷歌、亚马逊等十大公司微服务案例精选

自去年以来,微服务受到了前所未有的关注,众多的互联网巨头开始实施微服务架构并取得了不错的反响,话不多说,今天我们就为大家盘点一下谷歌、亚马逊等十大科技公司的微服务实践案例。 1. 谷...

good_rain
2016/12/08
23
0
微服务概述

微服务的诞生 微服务架构(Microservice Architect)是一种架构模式,它提倡将单块架构的应用划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的...

李景枫
2016/04/17
122
0
基于Docker的开发模式驱动持续集成落地实施

11月30日,资深质量优化专家陈能技老师,在【DBA+社群】中间件用户组进行了一次主题为“基于Docker的开发模式驱动持续集成落地实施”的线上分享。小编特别整理出其中精华内容,供大家学习交流...

陈能技
2015/12/02
0
0
80/20定律:在生产环境中使用容器所能带来的收益

今天许许多多的人都在谈论容器,容器编排,以及容器相关的生态,而相比之下却只有少数几个组织能够真正的在生产中使用容器。 鉴于使用容器所能带来的那些好处,特别是与其他方案相比,你不得...

Docker
2018/02/05
0
0

没有更多内容

加载失败,请刷新页面

加载更多

NIO基于长度域的报文在Netty下的解码

1, 先复习一下粘包/拆包 1.1, 粘包/拆包的含义 TCP是个“流”协议, 并不了解上层业务数据的具体含义, 它会根据TCP缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被TCP...

老菜鸟0217
今天
8
0
从零开始搭建spring-cloud(2) ----ribbon

在微服务架构中,业务都会被拆分成一个独立的服务,服务与服务的通讯是基于http restful的。Spring cloud有两种服务调用方式,一种是ribbon+restTemplate,另一种是feign。 其实我们已经在上...

Vincent-Duan
今天
17
0
get和post的区别?

doGet:路径传参。效率高,安全性差(get的传送数据量有限制,不能大于2Kb) doPOST:实体传参。效率低,安全性好 建议: 1、get方式的安全性较Post方式要差些,包含机密信息的话,建议用Pos...

花无谢
昨天
4
0
当谈论迭代器时,我谈些什么?

当谈论迭代器时,我谈些什么? 花下猫语:之前说过,我对于编程语言跟其它学科的融合非常感兴趣,但我还说漏了一点,就是我对于 Python 跟其它编程语言的对比学习,也很感兴趣。所以,我一直...

豌豆花下猫
昨天
14
0
10天学Python直接做项目,我做了这5件事

初学者如何尽快上手python? 市面上关于如何学python的资料很多,但是讲的都太复杂。 我就是很简单的几句话,从小白到开发工程师,我只做了五件事。 我觉得任何商业计划书如果不能用几句话讲...

Python派森
昨天
7
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部