运维就要无所不能，无所不会
问题场景还原
服务治理概念
单体应用
SOA
新一代的spring cloud
微服务治理
后小结
[服务治理]再次遇到10年前问题，我是这么做的
副标题: 如何成为更的自己。
大家好，我是史丹利「Stanley」.今天我们来聊如果你遇到的问题是10年前已经遇到过的，你该怎么做？其实，我更想聊的是如何成为更的自己。
本次希望能为大家如下一些收获：
成长之路的方法论 微服务治理的入门
问题场景还原
今天遇到一个非常经典的问题，详情描述如下「PS: 稍微有点复杂，可能需要大家多一点耐心」：
问题共涉及5个部门
运维(小A)、后台开发(小B)、前台开发(小C)、测试(小D)、IOS/安卓手机端开发(小E)
乱入的角色：测试小(F),测试小(G),测试小(H)，测试小(K)，运维小(L)
问题表现
测试同学功能性测试某的icon点击后没反应
问题症结
不知道该问题找谁处理！
问题处理详细过程
测试同学(小D)先找到后台开发(小B)，小(B)说不清楚怎么处理，他们程序没问题，猜测入口没有配置 测试同学(小D)遂找到另外一位熟悉业务的测试同学(小F), 小F说需要找运维(小A)配置 测试同学(小D)又找到运维(小A),但又讲不清楚需要运维(小A)配置什么 运维同学(小A)根据经验猜测需要找前台开发(小C)，于是众人又找到(小C)，小C说不一定是没有配置，需要IOS/安卓手机端开发(小E)抓包看下 小E看完后，又把后台开发(小B)抓过来，说流量APP接受到了，但流量有没有到你们后台需要你们跟踪下日志 后台开发(小B)抓完日志后发现，需要运维(小A)在Nginx配置一段跳转，把流量导进来 运维(小A)根据开发同学提供的OA，靠猜测和经验瞎配一通，测试(小D)验证后，依然有问题，但报错已经有所变化，问题有所进步，请后台开发(小B)排查 后台开发(小B)排查后，发现在网关处要添加一段类似白名单的配置。 运维(小A)找到运维小(L)，但小(L)说，测试环境需要同学自己配置，运维没有权限 于是测试(小D)找到测试小(G),测试小(G)一通操作后，发现自己权限不足，需要找测试小(H) 于是测试(小D)找到需要找测试小(H)添加一段白名单后，问题解决
问题终处理方案
非常简单！
添加 nginx入口添加 gateway白名单
即可
但是！大家看看问题处理的详细流程，有什么感觉，太难了，日了狗的感觉有没有！。。。这么一个小破问题，Block了2天。
而我们公司总共才不到3000人。上海所有的IT团队也不过400人！。。明明没有大公司的实力，却得了大公司的病。
这个场景不禁让我想起10年在腾讯的工作经历，我们当时经常遇到这样的问题：
一个问题A找B，B找C，C找D，D找E，E找，F找A。留下一脸蒙逼的A...
A觉得太冤了呀。本来是自己遇到的问题，后竟然还需要小A处理，而且小A还不知道怎么处理。。。。
我原以为这是个故事，后来发现就是发生在我身上的真事，还是两次。。。
当我再次遇到这个的时候，我的反应是这个问题很经典。相比10年前只有一脸蒙逼，现在多了很多方案。
明显：
大到公司的组织架构是有明显问题的，导致技术架构也不清晰，各部门各自为战，自扫门前雪，终导致这样的结果 小到部门自组织能力，已经暴露出严重的职责分工问题。横向切割的太狠会导致员工对业务的理解程度，纵向切割的太狠会导致员工停驻在自己的一亩三分地。团队大了后，充分考验团队管理人的水平。
公司组织架构不是我们本次要讨论的话题。重点是本次我是如何处理的。
原则上问题解决后，这个问题就可以结束了，但作为运维部落的粉丝，怎么可能会放弃这么好的学习机会。结合这么多年的工作经验，我脑海里冒出来一个词: 服务治理。
这个词我一直知道，但也只是仅仅是知道的层面。我在公司问了15年左右工作履历的java开发负责人。没想到这货和我是一个理解程度，甚至还要反问我 什么是服务治理。。。。哭.gif.
于是，昨天研究到凌晨，结合开发同学现在的微服务治理的工作模型，我结合自己的粗浅理解，斗胆给大家普及下服务治理的
概念 场景 运维需要掌握到什么程度
服务治理概念
首先，作为10年老司机，我先斗胆预测大家对服务治理也只是字面理解。这里有个好消息，大家不必焦虑，据我研究市场无论是职场体系还是学术体系，对服务治理都没有一个统一的标准和理解，各公司各自为营。总的适用标准，合适就是好的。
服务治理其实是随互联网的高并发特色衍生出来的。 即，当技术架构复杂到一定程度时，都需要对问题梳理、改进优化。服务治理的本质其实是对复杂度的管理。无论是人月神话，还是人们常讲的技术银弹都是和复杂对抗的过程。
单体应用
业务早期流量不大时，多为单体应用，即所有模块AllInOne，即可满足应用所需。随着流量不断增长及微服务、容器化、网格服务的越来越流行，庞大的服务节点数量、日趋复杂的服务分层、离散的组织协同、扁平化的管理模式让服务治理的广度、深度、难度都达到前所未有的程度。单纯依靠微服务框架层面的治理是远远不够的，需要构建贯穿研发、测试、运维、管理各领域的立体式的深度治理体系
这个阶段谈不上服务治理，svn，chm文档，接口查询接入即能完成接口管理。说白了，就是文档管理的过程
SOA
随着IT的建设，各部门之间互联互通的需求越来越多，常规提供api接口方式管理难度效果随数量直线下降。
后来IBM提出的SOA面向服务开发架构兴极一时。并制定了一系列的标准。SOA 核心的诉求就是构建一条企业服务总线（ESB）。通过 SCA 规范开发服务适配器，将不同的异构系统接入服务总线，通过 SDO 标准进行请求数据封装，服务之间通过 WebService 协议进行互相调用，通过 BPEL 流程标准对服务进行流程化的编排，创建出来的服务可以通过 UDDI 协议对外暴露，以供第三方应用或服务调用。由于涉及的软、硬件资源越来越多，“治理”的需求也就应运而生。事实上，服务治理这个概念是随着 SOA 技术的兴起被同步提出来的。
本段援引自info[1]
简单点说，就是通过技术架构来解决人治的问题。但同步有如下问题，致使SOA架构并未在业内广泛推广。
实现复杂，流程复杂，治理成本高 侵入式太强，需要组织变更，甚至需购买IBM的咨询服务 自动化程度不够
基本上解决了老问题，引入了新问题。
新一代的spring cloud
新一代的spring Cloud 相对SOA，单纯从技术角度实现简化版分布式系统。从架构设计上为开发人员提供快速构建分布式系统架构的工具，例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁定，领导选举，分布式会话，集群状态等。大大降低大型项目管理门槛
Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
Feign：基于Ribbon和Hystrix的声明式服务调用组件；
Zuul：API网关组件，对请求提供路由及过滤功能。
sping cloud 解决了大部分Java应用的微服务场景，但其它非工程性言语有微服务之路全靠经验和技术。随着容器化的逐渐普及。微服务治理也日益成熟。
微服务治理
随着近几年容器技术的快速发展，服务封装及部署的成本越来越低。一方面，微服务的模块越来越小，另外一方面，随着互联网行业发展，平台规模越来越大。微服务管理难度更大，量变导致质变，我们的开发模式、测试模式、运维模式都会受到冲击。
容器化编排服务为容器化可用和拓展铺平道路，但微服务的开发，上线，运维，各部门之间的协调仍离不开人。像文章伊始的问题依然无法解决。
这个问题，李鑫老师则给出了更为专业的技术解决方案。这比我伊始想到的网关架构角度又有了更高维度的提升。线下管理->分析度量->线上管控，实现线上线下链接闭环。
参考如上的架构，其实我司在技术栈的应用很全面，在今年容器化后，技术栈也追上业内平均水平，但综合公司业务特色、组织构架、文化氛围，有很多问题依然在路上：
事情推进难 跨部门合作不畅 CICD部分流程断档，容器化后，以前CICD面临废弃重构 平台工具体验极差 制度流程缓慢，有制度无落地 等吧...
当然了，每家公司必然存在各类问题，如上这些问题必然也不是我司个例， 李老师的这篇微服务治理思想[2]值得学习10遍。希望能从中找到更佳解决方案。
后小结
但《精进——如何成为一个很厉害的人》 和《程序员修炼之道: 从小工到专家》里的几句话送给自己，分享给大家：
不要把一个经验用10年 DRY(Don't Rry Yourself!) 做一个主动探索的学习者 高标准”要求自己-追求好而不是好
over~ 希望大家今天有所收获
