作者 小米云平台 王刚
架构师是一个高大上的头衔，在百度百科中对架构师的定义是“一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。”ArchSummit 是一个知名的架构师技术交流论坛，高达 6800 元人民币的门票（当然人多的话有打折）也没能阻挡前来参会的架构师们的热情，也直接反映了架构师们一般都不差钱。我是一名工程师，做过搜索、也做过推荐、搭过数据平台、也挖过用户画像，从零开始建设过若干平台和系统，不敢妄称自己为架构师，但有一些经验体会可以分享。
系统架构的选择往往没有对与错，工程师们常常面对的是各种取与舍的矛盾。在众多的矛盾中，首当其冲的当属业务和技术的矛盾，业务快速发展，产品对需求的时间点要求感人，“帅哥，这个需求今天能完成吗？”，“这是老板的需求，赶快实现一下”。应对扑面而来的需求，工程师们往往疲于奔命，使用各种短平快的方法来满足业务的需求，长此以往，整个系统变得错综复杂，臃肿不堪，难以维护。一个好的架构需要在应对业务需求的同时，持续提炼通用化的模块，通用层基础且稳定。在通用模块的基础之上构建出适配层，由适配层处理复杂多变的业务需求，适配层灵活且多变。在技术上不断沉淀基础的通用模块，这不仅不会成为工程师们额外的开发负担，反而可以提升业务需求的实现效率，提高系统的健壮性和可持续发展。解决业务和技术这一对矛盾，需要工程师站在业务和技术中间，不偏不倚。
优秀的系统架构面对的第二个矛盾是技术和运营的矛盾。 工程师们往往热爱新和奇的技术，重视新功能的开发，从 0 分做到 60 分的过程总是令人愉悦的，一切按照预期的演进是那么的美好。随着系统投入使用，数据规模越来越大、用户量和访问量逐步增大，算法效果需要不断提高，原有的架构暴露出来的问题也逐步增多。架构的演进进入了深水区，是抛弃原有架构进行重构，还是在现有系统中进行持续的演进，工程师们往往会遇到选择的难题。一个好的系统是要靠持续深入的运营来构建的，这里的运营是一个泛指的概念，指代构建系统中各种监控、调试信息、数据统计分析、数据对比等。一个系统不论是重构，还是持续演进，都需要开发全方位的运营系统来了解当前架构中的每一个环节。系统架构从 60 分演进到 100 分是一个艰苦的过程，没有一个系统是在一开发出来就解决了所有的问题的，提高运营能力是架构演进的基础，这本身不是一个技术问题，而是意识问题，需要工程师们做大量细致深入的调研和思考。
最后要说的是全局最优和局部最优的矛盾。我们在开发中常常遇到，当针对某个问题进行优化后，系统中又出了其他问题，也是俗话里说的头疼医头、脚疼医教、治标不治本。当你是从 0 开始搭建一个系统，对系统的各个环节和历史演进非常清楚，也就比较容易的从全局角度思考和解决问题。但对于复杂系统，大部分工程师往往只关注到系统的某一部分，解决问题的思路是受限于眼界，容易陷入至局部最优，而且往往局部的解决办法相对全局而言更复杂更间接。工程师需要有开阔的眼界，从更高层面理解系统架构，从而了解问题产生的本质，从全局角度出发予以解决。
本来是想多例举一些工作中遇到的例子来说明我在平台架构开发中遇到的矛盾，但限于时间太紧，只能下次有机会再和大家继续交流，也欢迎大家和我直接联系。
目录
热点 | Hot
如何使代码审查更高效
用 10% 的自主时间提升学习
推荐文章 | Article
京东 Nginx 平台化实践
携程基于 Storm 的实时大数据平台实践
基于 Lambda 架构的股票市场事件处理引擎实践
观点 | Opinion
多形态 MVC 式 Web 架构的分类
评论