谈谈架构标准化的问题（跟运维有关系？）

本来这篇是打算直接写运维角色到底发生了哪些变化，起到了哪些更有价值地作用的，但是觉得铺垫还不够，所以先写写架构标准的问题，下篇就差不多就可以直接写角色的转变了。

一、问题回顾

接上篇《运维架构是全站技术架构中不可分割的一部分》，文中提到一个问题，运维架构和技术架构的脱节这个问题到底出在哪了？到底谁应该承担这个责任？

一开始，我个人第一反应，承担这个责任的或许应该是架构师这样的角色吧，毕竟这不是个单纯的技术问题。

但是仔细考虑过后，我觉得这样也会有问题。因为从服务化之后，整个架构就已经是去中心化的了，我们可以看一下自己的周边，现在架构师的角色已经更多的往垂直领域发展了，如业务架构师（交易、支付、商品、营销、类目等），或者某个技术领域的专家，如分布式服务、消息、缓存和DB，更大的方向上如大数据、搜索等等方面。我想这也是去中心化之后的必然结果，大家都是朝着某个更加聚焦、更加专业的方向发展。因为每个专业方向的特点又不相同，这时就很难再出现能把全站的架构讲的清清楚楚的人了。

所以，我们如果只是想当然的认为应该是xxx角色要承担责任，这样难免会片面。

二、怎么解决呢？

现实情况下，既然靠单个人或角色解决不了的问题，那就靠团队，靠良好的组织协作、靠共同遵守的架构契约来完成。这里我是从运维的角度来考虑架构契约，可能更多的还有前后端架构契约、接口设计契约等等，这个更偏向开发内部自行遵守，就不班门弄斧了。

三、架构契约中的运维部分—架构标准化

上面提到的团队和团队协作，这个就不多说了，组织定期的例会讨论，多参加彼此技术方案会议，随时随地的交流，这个只要保持开放的心态和合作模式都是可以做到的。

还是想再说一下，千万不要出现，开发说这个应该是运维考虑的事情，跟我们无关，运维说这个应该是开发的事情，开发想不不清楚让我们怎么办？如果都是这种心态就完蛋了，建议双方都往前走一步，大家要有共赢的心态才可以。

但是沟通讨论以及会议只是形式，最关键和重要的是各方要能制定出共同遵守的架构契约来。简单来说，就是要遵循统一的标准，并使其横向延伸到运维阶段的平台中去，一脉相承，比如发布系统、监控、稳定性等平台系统，从而使得运维的体系能够更好的支持业务架构体系。而不是我们之前所说的，每个运维的平台都是一个个孤岛，无法形成体系。

重点谈谈关于架构标准化，之前提到的标准，更多的还是偏运维层面的标准，比如硬件资源标准、应用标准、部署标准等，这些在《如何打造一个以应用为核心的运维体系》文章介绍过，不多解释。但是架构标准就很少有提到了，直观看上去这一点跟运维并没有很大的关系。

但事实正好相反，我们可以一起分析下。按照我们自己的经验，在做业务服务化的早期，我们也没有意识去关注架构标准，结果就会出现以下几个场景：

1、分布式服务化框架，虽然绝大部分团队用Java，但是因为有的团队对PHP特别熟悉，所以就用PHP去做服务化，后面遇到的问题就是Java的服务化接口和PHP的服务化接口该怎么相互调用，所以到了后来我们的服务化框架还要提供PHP-Proxy来适配PHP的服务化接口；

2、分布式DB中间件，有的团队觉得我们自研的分布式DB框架不好用，对分库分表的支持不够友好，就去自研一套出来，或者去引入其他的开源的框架进来。平时使用没问题，但是到了后期要做一些统一的策略就很难搞，比如DB访问策略、账号密码管控、路由策略优化、慢SQL统计和优化等等；

3、分布式的缓存，有的直接使用redis，redis可能还会有主备或者Cluster，有的搞个开源的Codis方案等等

4、接入层上，有的期望用Nginx直接做7层负载，版本上有期望用TEngine，有的期望用Openresty，还有的期望用LVS有个VIP就够了；

5、稳定性上，比如全链路，如果要做统一的Trace打点，本来在一套框架上就可以实现的，结果要再多个框架上实现。对于开关、限流、降级这些策略也一样，很难统一。实际上为后续的体系建设增加了很多额外的工作；

6、上线后的日志采集，因为跟其它团队使用的框架不一样，自己在搞一套日志采集的系统，说白了都是ELK，但是因为太个性化不统一，只能自己搞个；

7、。。。。。

以上，还不包括之前提到的类似于Java版本，启停方式，web容器类型、各种部署目录等等。所以到了运维阶段，不统一不标准，压根就没法玩下去了。这个时候我就不难理解，架构的标准对于运维阶段的建设其实是有决定性的意义的。

可能有的人会说我们做的low，管理上有问题，我不否认，现在回过头来看，当时确实是low了，管理上确实无意识没经验。不过在当时的情况下，特别是在初期，除非团队中能有一个技能和经验非常全面的角色，端到端hold住全局，否则只能是靠摸爬滚打摸索出来。现实情况，我之前经历的多个项目，包括在华为的大型的电信和互联网项目，以及当前我接触到的很多的团队也仍然还是这种玩法，必然得走很长一段分久必合的道路才能走到正道上来，而且这种能力超群的牛人，我不敢说没有，但是我能遇到的真的凤毛麟角。 根本上，还是经验意识上的缺失，而且在这一块，架构的资料中貌似很少有涉及到这一部分的内容。当然，最终期望这样的经验能够给到业界一些帮助和指导。

所以这个时候，运维必须要有意识参与进去制定架构标准，并强势的约束，所谓的约束是要体现在技术平台上的，比如在发布系统和安装部署上做约束，以Java举例，只支持固定1-2个Java版本，目录都约定好，容器约定好，服务化的框架约定好，这些约定好之后，如果线上要做变更，做发布，必须接入这套体系，否则坚决不让你上线，而且到了后面随着集群规模的增大，开发想绕都绕不开，因为完全靠手工已经是不可能的事情了，比如下图，是一个应用单机的发布部署过程，如果这个应用有100台机器怎么办？

再比如，稳定性上，我们做全链路，我们只针对标准的分布式框架做打点（当然精力有限，也不可能支持所有的框架），如果你选择的不是标准框架，而是自研或自己引入的，抱歉，打点只能自己做。这个时候遇到性能瓶颈或链路上的异常，如果使用的是标准框架，有全链路根据平台的支持，日志采集、分析和报表呈现就很方便，问题定位过程相对高效一些，如果不是，抱歉，只能手工的去定位了，一个请求分布那个应用的那台机器上去了，在这样一个分布式的环境中，效率可想而知。同样的，开关、限流、降级策略下发等等，一样会有相同的问题。

作为线上资源的控制者，稳定性的Owner，运维，你有权利Say No！

当然，历史原因造成的架构标准不统一的问题，是需要Dev和Ops共同合作去改造的，而不是很强势地单纯地去提要求，这个涉及双方合作方式的问题，后面再单独写篇文章。

四、我们参与了架构标准的制定，接下来呢？

上篇讲了技术架构与运维脱节的问题，这篇算是进了一步，运维真正的参与到了架构设计中，确切说是架构标准制定中，运维虽然不是架构的实现者和开发者，但确是维护架构统一和标准的执行者。整个过程，运维的角色和作用也在悄然发生着变化。

本来这篇是打算直接写运维角色到底发生了哪些变化，起到了哪些更有价值地作用的，但是觉得铺垫还不够，所以先写写架构标准的问题，下篇就差不多就可以直接写角色的转变了。

未完待续。