绑定完请刷新页面
取消
刷新

分享好友

×
取消 复制
[服务治理]再次遇到10年前问题,我是这么做的
2021-01-14 15:55:11

运维就要无所不能,无所不会

  • 问题场景还原

  • 服务治理概念

    • 单体应用

    • SOA

    • 新一代的spring cloud

    • 微服务治理

  • 最后小结

[服务治理]再次遇到10年前问题,我是这么做的

副标题: 如何成为更优秀的自己。

大家好,我是史丹利「Stanley」.今天我们来聊如果你遇到的问题是10年前已经遇到过的,你该怎么做?其实,我更想聊的是如何成为更优秀的自己。

本次希望能为大家如下一些收获:

  1. 成长之路的方法论
  2. 微服务治理的入门

问题场景还原

今天遇到一个非常经典的问题,详情描述如下「PS: 稍微有点复杂,可能需要大家多一点耐心」:

  • 问题共涉及5个部门

    运维(小A)、后台开发(小B)、前台开发(小C)、测试(小D)、IOS/安卓手机端开发(小E)

    乱入的角色:测试小(F),测试小(G),测试小(H),测试小(K),运维小(L)

  • 问题表现

测试同学功能性测试某的icon点击后没反应

  • 问题症结

不知道该问题找谁处理!

  • 问题处理详细过程
  1. 测试同学(小D)先找到后台开发(小B),小(B)说不清楚怎么处理,他们程序没问题,猜测入口没有配置
  2. 测试同学(小D)遂找到另外一位熟悉业务的测试同学(小F), 小F说需要找运维(小A)配置
  3. 测试同学(小D)又找到运维(小A),但又讲不清楚需要运维(小A)配置什么
  4. 运维同学(小A)根据经验猜测需要找前台开发(小C),于是众人又找到(小C),小C说不一定是没有配置,需要IOS/安卓手机端开发(小E)抓包看下
  5. 小E看完后,又把后台开发(小B)抓过来,说流量APP接受到了,但流量有没有到你们后台需要你们跟踪下日志
  6. 后台开发(小B)抓完日志后发现,需要运维(小A)在Nginx配置一段跳转,把流量导进来
  7. 运维(小A)根据开发同学提供的OA,靠猜测和经验瞎配一通,测试(小D)验证后,依然有问题,但报错已经有所变化,问题有所进步,请后台开发(小B)排查
  8. 后台开发(小B)排查后,发现在网关处要添加一段类似白名单的配置。
  9. 运维(小A)找到运维小(L),但小(L)说,测试环境需要同学自己配置,运维没有权限
  10. 于是测试(小D)找到测试小(G),测试小(G)一通操作后,发现自己权限不足,需要找测试小(H)
  11. 于是测试(小D)找到需要找测试小(H)添加一段白名单后,问题解决
  • 问题最终处理方案

非常简单!

  1. 添加nginx入口
  2. 添加 gateway 白名单

即可

但是!大家看看问题处理的详细流程,有什么感觉,太难了,日了狗的感觉有没有!。。。这么一个小破问题,Block了2天。

而我们公司总共才不到3000人。上海所有的IT团队也不过400人!。。明明没有大公司的实力,却得了大公司的病

这个场景不禁让我想起10年在腾讯的工作经历,我们当时经常遇到这样的问题:

一个问题A找B,B找C,C找D,D找E,E找,F找A。留下一脸蒙逼的A...

A觉得太冤了呀。本来是自己遇到的问题,最后竟然还需要小A处理,而且小A还不知道怎么处理。。。。

我原以为这是个故事,后来发现就是发生在我身上的真事,还是两次。。。

当我再次遇到这个的时候,我的第一反应是这个问题很经典。相比10年前只有一脸蒙逼,现在多了很多方案。

![企业微信截图](http://oss-qiniu.ssforce.cn/Screen Shot 2021-01-14 at 12.11.33 PM.png)

明显:

  1. 大到公司的组织架构是有明显问题的,导致技术架构也不清晰,各部门各自为战,自扫门前雪,最终导致这样的结果
  2. 小到部门自组织能力,已经暴露出严重的职责分工问题。横向切割的太狠会导致员工对业务的理解程度,纵向切割的太狠会导致员工停驻在自己的一亩三分地。团队大了后,充分考验团队管理人的水平。

公司组织架构不是我们本次要讨论的话题。重点是本次我是如何处理的。

原则上问题解决后,这个问题就可以结束了,但作为运维部落的粉丝,怎么可能会放弃这么好的学习机会。结合这么多年的工作经验,我脑海里冒出来一个词: 服务治理

这个词我一直知道,但也只是仅仅是知道的层面。我在公司问了15年左右工作履历的java开发负责人。没想到这货和我是一个理解程度,甚至还要反问我 什么是服务治理。。。。哭.gif.

于是,昨天研究到凌晨,结合开发同学现在的微服务治理的工作模型,我结合自己的粗浅理解,斗胆给大家普及下服务治理的

  • 概念
  • 场景
  • 运维需要掌握到什么程度

服务治理概念

首先,作为10年老司机,我先斗胆预测大家对服务治理也只是字面理解。这里有个好消息,大家不必焦虑,据我研究市场无论是职场体系还是学术体系,对服务治理都没有一个统一的标准和理解,各公司各自为营。总的适用标准,合适就是最好的

服务治理其实是随互联网的高并发特色衍生出来的。 即,当技术架构复杂到一定程度时,都需要对问题梳理、改进优化。服务治理的本质其实是对复杂度的管理。无论是人月神话,还是人们常讲的技术银弹都是和复杂对抗的过程。

单体应用

摘自infoq李鑫服务治理分享-侵删

业务早期流量不大时,多为单体应用,即所有模块AllInOne,即可满足应用所需。随着流量不断增长及微服务、容器化、网格服务的越来越流行,庞大的服务节点数量、日趋复杂的服务分层、离散的组织协同、扁平化的管理模式让服务治理的广度、深度、难度都达到前所未有的程度单纯依靠微服务框架层面的治理是远远不够的,需要构建贯穿研发、测试、运维、管理各领域的立体式的深度治理体系

这个阶段谈不上服务治理,svn,chm文档,接口查询接入即能完成接口管理。说白了,就是文档管理的过程

svn文档列表
接口标准文档

SOA

随着IT的建设,各部门之间互联互通的需求越来越多,常规提供api接口方式管理难度效果随数量直线下降。

后来IBM提出的SOA面向服务开发架构兴极一时。并制定了一系列的标准。SOA 最核心的诉求就是构建一条企业服务总线(ESB)。通过 SCA 规范开发服务适配器,将不同的异构系统接入服务总线,通过 SDO 标准进行请求数据封装,服务之间通过 WebService 协议进行互相调用,通过 BPEL 流程标准对服务进行流程化的编排,创建出来的服务可以通过 UDDI 协议对外暴露,以供第三方应用或服务调用。由于涉及的软、硬件资源越来越多,“治理”的需求也就应运而生。事实上,服务治理这个概念是随着 SOA 技术的兴起被同步提出来的。

本段援引自info[1]

SOA架构,援引自infoq-侵删

简单点说,就是通过技术架构来解决人治的问题。但同步有如下问题,致使SOA架构并未在业内广泛推广。

  • 实现复杂,流程复杂,治理成本高
  • 侵入式太强,需要组织变更,甚至需购买IBM的咨询服务
  • 自动化程度不够

基本上解决了老问题,引入了新问题。

新一代的spring cloud

新一代的spring Cloud 相对SOA,单纯从技术角度实现简化版分布式系统。从架构设计上为开发人员提供快速构建分布式系统架构的工具,例如配置管理,服务发现,断路器,智能路由,微代理,控制总线,一次性令牌,全局锁定,领导选举,分布式会话,集群状态等。大大降低大型项目管理门槛

  • Eureka:服务治理组件,包括服务端的注册中心和客户端的服务发现机制;

  • Ribbon:负载均衡的服务调用组件,具有多种负载均衡调用策略;

  • Hystrix:服务容错组件,实现了断路器模式,为依赖服务的出错和延迟提供了容错能力;

  • Feign:基于Ribbon和Hystrix的声明式服务调用组件;

  • Zuul:API网关组件,对请求提供路由及过滤功能。

spring cloud

sping cloud 解决了大部分Java应用的微服务场景,但其它非工程性言语有微服务之路全靠经验和技术。随着容器化的逐渐普及。微服务治理也日益成熟。

微服务治理

后端架构演变图-援引自csdn-侵删

随着近几年容器技术的快速发展,服务封装及部署的成本越来越低。一方面,微服务的模块越来越小,另外一方面,随着互联网行业发展,平台规模越来越大。微服务管理难度更大,量变导致质变,我们的开发模式、测试模式、运维模式都会受到冲击。

容器化编排服务为容器化可用和拓展铺平道路,但微服务的开发,上线,运维,各部门之间的协调仍离不开人。像文章伊始的问题依然无法解决。

这个问题,李鑫老师则给出了更为专业的技术解决方案。这比我伊始想到的网关架构角度又有了更高维度的提升。线下管理->分析度量->线上管控,实现线上线下链接闭环。

援引自infoq-李鑫服务治理-侵删

参考如上的架构,其实我司在技术栈的应用很全面,在今年容器化后,技术栈也追上业内平均水平,但综合公司业务特色、组织构架、文化氛围,有很多问题依然在路上:

  • 事情推进难
  • 跨部门合作不畅
  • CICD部分流程断档,容器化后,以前CICD面临废弃重构
  • 平台工具体验极差
  • 制度流程缓慢,有制度无落地
  • 等吧...

当然了,每家公司必然存在各类问题,如上这些问题必然也不是我司个例, 李老师的这篇微服务治理思想[2]值得学习10遍。希望能从中找到更佳解决方案。

最后小结

但《精进——如何成为一个很厉害的人》 和《程序员修炼之道: 从小工到专家》里的几句话送给自己,分享给大家:

  • 不要把一个经验用10年
  • DRY(Don't Rry  Yourself!)
  • 做一个主动探索的学习者
  • 高标准”要求自己-追求最好而不是好

over~ 希望大家今天有所收获




分享好友

分享这个小栈给你的朋友们,一起进步吧。

新运维新数据
创建时间:2020-07-15 15:50:20
一线运维工程师直击现场,分享运维日记、小工具的使用、数据库运维过程中遇到的那些坑(附解决方案)。
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

栈主、嘉宾

查看更多
  • Bsolar
    栈主

小栈成员

查看更多
  • apsbb
  • ?
  • gaokeke123
戳我,来吐槽~