加入收藏 | 设为首页 | 会员中心 | 我要投稿 厦门网 (https://www.xiamenwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长百科 > 正文

链家网技术总监陈尔冬:链家网的第三种运维

发布时间:2021-01-12 23:36:20 所属栏目:站长百科 来源:网络整理
导读:《链家网技术总监陈尔冬:链家网的第三种运维》要点: 本文介绍了链家网技术总监陈尔冬:链家网的第三种运维,希望对您有用。如果有疑问,可以联系我们。 作者简介: 陈尔冬 链家网 技术总监 曾于新浪任职技术总监,负责私有云平台研发与运维并支撑新浪微博从

我举一个例子,如果我所在的公司很大.然后有上百个团队去做开发,每一个团队开发的技术架构都不一样,使用的语言也不一样:有的是 JAVA,有的是 PHP,有的是 Python,有的是 C/C++.即便同样是 JAVA 语言,有的是 HTTP 协议的,有的是私有协议.

那么如果我的团队来运维这所有的系统,这个架构相当乱.需要为所有的这些系统做运维,怎么做?

开发团队很大,加起来有上万人,我就算有几百人,肯定也做不过来.这时候就适合使用容器技术,实现序中有乱.乱在你集装箱内,对我的团队来讲,这里就是上万个集装箱,每一个集装箱的尺寸是完全一样的,我做一个基础设施可以去把集装箱从这里搬到那里,就搞定了.

集装箱内的东西每个研发团队自己去搞定,这是一种工作模式.我认为容器在这个领域是非常适合的,也就是没有办法让架构从头到脚有序的时候.

但是,我们工作的场景是什么样的呢?有的公司里面是不乱的.比如我原来在新浪的时候有一段阶段新浪所有项目都是 PHP,而且都用 Apache 做 Web 服务器.我们又设立了一些规范让研发团队去遵守,整体架构完全统一的.这时候我们还要必要容器吗?

我个人觉得这是需要考虑的,为什么呢?因为如果你要引入容器,终究会增加成本.等价交换是这个世界的铁则.你用了新的技术容器,它帮你解决了序中有乱的问题,你就要管理它.

3.4 容器Tomcat

我们如果采用新技术,但只有五个人,首先我有疑问:这能搞得定吗?是否可以不用容器,为什么一定要用呢?.再则,我们的架构里其实已经有容器了.Tomcat 就是个容器,从系统层看到的都是 Tomcat,但里面是不同的 JAVA 的程序,其实也是个乱之有序的架构.

这时候有朋友会提出问题,说 Docker 是可以实现资源隔离的.Tomcat 没有这个功能,可能会资源互相影响.其实 Docker 实现资源隔离是利用了 CGroup.为什么 Docker 用了 CGroup,我们不能用呢?最后看看一个没有 Docker 的弹性计算方案.

下面那三个我们可以认为跑在同一台服务器上.同一台服务器跑了多个应用实例,我们可以理解为每个 Tomcat 监听不一样的端口,我在七层负载均衡上把端口映射到不一样的端口上.

这个时候一个服务器上就有多个容器了,只不过容器是 Tomcat,不是 Docker.我们再对这多个 Tomcat 利用?CGroup?做资源隔离甚至资源统计.如果你有一套强大的管理系统,可以把这七层映射关系以及这些 Tomcat 配置文件配置起来的话,那么这套弹性计算云就完成了.

我个人理解,这套基础设施比 Docker 对于我的团队来讲更容易管理.因为我的团队这些工程师,他以前是做传统运维的,对 Tomcat 很熟,对于 Ansible、Puppet、SaltStack 这些配管工具很熟.

他们管理物理服务器非常熟悉,但让他们今天开始管容器,他需要一些时间.再加上容器项目本身成熟度问题,我认为对我团队这就是目前为止最好的方案.

4、最合适的才是最佳方案

未来 Tomcat 会不会变成容器呢?不好说.也许以后 Docker 成熟了,某些方面比我这个方案更好.现在这个时间点,我认为对于我的团队来讲它是一个更好的方案.

话又回到开篇所提及.对于您的团队是不是一定是这个方案是最好的方案呢?也许吧.

但我可以把我思考的思路以及我的理念写出来去做一个分享.在您的场景可以按我们的方式重新去思考一下,也许对您的团队来讲用 Docker 是更好的方式,也许您会探索出新的方案也未可知.

4.1 破解“被堵塞难题”

今天,大家都爱讲微服务.不管这个服务微不微,服务化已经是标配了.服务化后,整个架构中有数十个或上百个服务,每个服务做一件事,服务和服务之间的通信通过 RPC 实现.

4.2 探寻RPC堵塞的原因

服务之间 RPC 是很常见的事.如果一切都正常,那么一切都好,但如果某一个可能会被调用的资源变得慢的话,这个问题就来了.

如果有一个资源被调用慢,会产生两种结果:

  • 第一种可能的结果,因为后面资源调度慢.像图里面的,右面是我的资源,它反应很慢,你来一个请求,我可能要5秒响应,前面的调用方会被堵死.
  • 还有一种可能,前面队列发现设了一个超时时间,你 5 秒响应,我1秒就不调了,甚至 500 毫秒就不调了,然后我就会认为你这出错了.

对于超时这类的结果,一般调用方会重试,因为我调用没成功,逻辑跑不下去了.本来执行处理就慢,已经存在问题的情况了,但调用方又重试,500 毫秒就重试一次,就把这个服务给压死了.

友谊的小船说翻就翻,不光是服务会出现这样的故障,不同服务的团队也容易打翻友谊的小船互相指责.这边说我是被你拖死的,那边说你是把我压死的,你的超时时间设计不合理.

遇到这种情况怎么解决这个问题呢?回到刚才在容器技术用到的思考方式,要想去解决,我们先分析到底这个问题点在哪.

(编辑:厦门网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读