本文来自蘑菇街架构师赵成分享

截至 2018 年 4 月的数据，美丽说和蘑菇街整体的日活在百万级别，并且其中有 80% 的流量来自于移动 App 和小程序。

整个蘑菇街技术团队包括 600 多人的研发和 25 人的运维，主要的语言栈是 Java。

美丽说和蘑菇街合并之后，两个产品的技术体系和运维体系是以蘑菇街为主，并进行了深度融合。

2011 年时，蘑菇街刚刚成立，当时的业务模型是导购，所以架构也比较简单，基础设施层是 MySQL、Redis、Lucene 和爬虫，Web 层是 Nginx、PHP 和 FPM，代理层是 Nginx Proxy，也就是我们熟悉的 LNMP 技术栈，当时移动互联网还没有发展起来，所以主要的用户流量也是以 PC 为主。这个架构一直延续到 2013 年。

2014 年后，蘑菇街发现他们的 PHP 项目开始变得臃肿起来，这背后的原因主要有两方面，一方面是蘑菇街从最初只做导购的业务形态到后来做电商，业务体系越来越丰富，有了电商就会涉及用户、交易、商品、支付、广告等模块。

另外一个方面是在这几年的时间里蘑菇街的研发团队从最初的二三十人发展到了小三百人，扩展了 10 倍。

业务范围扩大，开发人员规模增长，自然而然，工程就变得复杂了起来。你想所有的研发人员都在一个臃肿的 PHP 项目里协同，这必然导致软件的高耦合性，直接后果就是研发效率降低，业务的迭代周期变长，改一处而动全身。

于是，蘑菇街开始着手解决这个问题，主要的解决手段就是拆，把大工程拆成小工程，当然，用专业的话来说就是“服务化”或者“微服务化”。

比如说，按照业务领域，可以拆分为商品应用、购物车应用等，而在商品应用中，又有很多的不同的服务，服务背后又有不同的 API。微服务化之后，整体的架构图如下所示：

从一个单体应用拆分为几十个甚至成百上千个应用，这对运维挑战很大。

直观来说，应用规模扩大，工作量就会翻倍，这是代价。并且把应用拆出来之后，他们并不是静态存在的，而是有非常复杂的调用关系，所以，大家经常讨论说服务拆分到什么颗粒度，这个问题其实需要与后方的运维成本进行权衡。

从蘑菇街整个的技术演进历程来看，引入微服务后，系统复杂度就远远超出了人脑的认知范围，更是超出了人力掌控的范畴。

这时候，就要通过技术手段来解决，技术手段包括工具、平台和体系。

那这些工具或者平台又由谁来建设呢？从蘑菇街的经验来看，它们需要运维和开发的紧密配合，所以这就会倒逼 Dev 和 Ops 融合。

DevOps 本质上是技术复杂度上升到一定程度的必然产物，而技术复杂度的因又是微服务和分布式架构。

换句话说，DevOps 的真正价值并不是单纯为了解决运维和开发之间矛盾，它一定是技术复杂度达到一定阈值之后的必然产物。

从这个角度来看，在微服务和分布式架构的模式下，运维应该是整个架构体系的一部分，是架构体系的延伸，它一定是不可分割的关键核心部分。

运维能力也应该是整个技术架构体系的能力表现，而不再是单纯运维的运维能力体现。

最后，赵成也点题说，在新的时代下，运维工作应该是基于架构去做的，因为没有哪一个运维体系是直接放到某个应用上做的。

这种情况下，必须把视角从运维中跳出来，从全局角度看事情。这一思维的转变值得每一个运维工程师和架构师思考。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 yubaibai360@qq.com 举报，一经查实，本站将立刻删除。