当前位置：首页 > news >正文

探寻架构师职责（一）----建新系统

news 2025/10/24 10:11:14

很多人一听到“架构师”这个词，脑子里可能会冒出几个印象：技术大牛、头发不多、天天画着一堆看不懂的框框图，感觉特高大上，但具体是干嘛的，又有点说不清楚。我们用两篇文章分别从「建新系统」和「维护老系统」这2个视角去看看架构师的真正的职责。

引言

如果把开发一个软件系统比作盖一栋大楼，那程序员的职责就是负责施工，保证按需完工，而架构师，就是那个在动工之前，把整栋大楼的设计图纸给画出来，并且对整个建造过程负责的建造师。

他的核心任务就一个：确保这栋“大楼”不仅能盖起来，还得质量好、户型合理、卖的好....并且以后想装修或者改造也方便。

听起来还是有点抽象？别急，我们来把架构师的工作拆解成几个更具体、更接地气的职责，并且请出我们今天的“特邀嘉宾”——老王，一位国内某知名电商公司的资深架构师，来看看他在日常工作中到底在忙活些啥。

职责一：画图纸 —— 系统的总设计师

这是架构师最核心、最基础的职责。在任何项目启动的初期，产品经理会提需求：“我们要做一个电商平台，要有商品展示、购物车、下单、支付这些功能。”

这时候，程序员们还不能马上开始写代码。架构师老王得先站出来，拿出画笔（当然，现在都用电脑软件了），开始“画图纸”。这份图纸，就是我们常说的系统架构图。

这份图纸要解决几个关键问题：

1. “房子”要分成几个“房间”？ —— 系统拆分

一个复杂的电商系统，不能把所有功能都塞在一个大房间里（据我了解，很多公司初期都是这么干的），那样会乱成一锅粥，出了问题都找不到在哪。老王会把系统拆分成一个个独立的“小房间”，比如“用户中心”、“商品中心”、“订单中心”、“库存中心”、“支付中心”等等。每个中心只负责自己的事，互不干扰。其实就是我们之前文章讲过的「高内聚、低耦合」的架构原则。

这样做的好处显而易见：用户中心的团队可以安心开发登录注册功能，不用关心商品是怎么上架的；订单中心的系统如果出了点小故障，也不会影响用户浏览商品。

2. “房间”之间怎么“走动”和“说话”？ —— 明确交互关系

拆分完之后，这些“房间”之间需要沟通。比如，用户下单时，“订单中心”得去问“库存中心”：“这个商品还有货吗？”；然后去问“用户中心”：“这个人的收货地址是啥？”；最后通知“支付中心”：“这笔订单该付款了”。

老王就要在图纸上把这些沟通的路径、方式（“接口”或“协议”）都设计好。是打电话（同步调用）还是发短信（异步消息）？都得规定清楚。这保证了各个模块之间协作顺畅，不会出现“鸡同鸭讲”的混乱局面。

3. “水电煤”线路怎么铺设？ —— 基础设施规划

除了功能模块，老王还要规划整个系统的“水电煤”，也就是数据库、缓存、消息队列这些基础组件。

数据存哪里？（数据库选型）：用户的个人信息、商品介绍这些重要数据，得找个安全可靠的地方存起来，比如用 MySQL 数据库。
怎么让访问更快？（缓存设计）：像双十一热门商品的详情页，每秒钟有几万次访问，总不能每次都去数据库里翻箱倒柜地找吧？太慢了。老王会设计一个“缓存系统”（比如用 Redis），就像在数据库前面开了个小卖部，把热门商品信息提前放在里面，谁要就直接拿，速度飞快。
怎么应对流量洪峰？（消息队列）：双十一零点一到，几百万人同时下单，订单系统肯定处理不过来。怎么办？老王会引入一个叫“消息队列”（比如用 Kafka）的东西，它就像一个巨大的蓄水池。用户的下单请求先不管三七二十一全扔进池子里，然后订单系统再根据自己的处理能力，慢慢从池子里捞请求来处理。这样，系统就不会因为瞬间压力过大而崩溃，保证了用户的下单体验。

所以你看，架构师的“画图纸”工作，绝不是随便画几个框框，而是对整个系统的深思熟虑，它决定了系统的“骨架”和“命脉”。

职责二：定选型 —— 技术方案的决策者

图纸画好了，接下来就得决定用什么“材料”来盖楼。是用水泥、砖头，还是用钢结构？

在软件世界里，“材料”就是各种技术。用 Java 语言还是 Go 语言？Web 框架用 Spring Cloud 还是 Dubbo？数据库用 MySQL 还是 MongoDB？

这个决策权，通常就在架构师手里。老王做决策时，不能凭自己的喜好，他需要综合考虑很多因素：

业务需求：要做一个需要处理海量数据的推荐系统，他可能会选择 Python，因为相关的算法库更成熟。要做一个高并发的后端服务，他可能会选 Go，因为它天生就擅长干这个。
团队能力：如果团队里大部分都是 Java 程序员，那硬要上一个全新的 Go 技术栈，学习成本太高，项目进度就没法保证。所谓“没有最好的技术，只有最适合的团队”。
社区生态和成熟度：一个技术是不是有很多人在用？出了问题在网上能不能找到解决方案？有没有大公司在背后支持？这些都很关键。选择一个冷门的技术，无异于把自己逼进死胡同。
成本：是选择开源的免费软件，还是购买昂贵的商业软件？是自建服务器，还是使用云服务？这些都直接关系到公司的预算。

架构师的技术广度要足够，否则会出现「手里只有锤子，看哪都是钉子」的情况。

职责三：定规范 —— 研发流程的守护者

大楼开始动工了，几百个建筑工人同时开工，如果没人管，张三在这里砌堵歪墙，李四在那边乱接电线，最后盖出来的肯定是个危楼。

所以，架构师老王还需要“定规矩”，也就是制定一系列的技术规范和标准。

代码怎么写？（编码规范）：变量怎么命名，代码怎么注释，每个函数不能超过多少行等等。这保证了大家写出来的代码风格统一，以后谁来接手都能看得懂。
质量怎么保证？（质量规范）：比如，每个功能上线前，单元测试覆盖率必须达到 80%；必须通过压力测试，模拟出双十一的流量来“压”一遍，看看系统会不会崩。
接口怎么开？（接口规范）：规定好各个系统之间接口的格式、参数、返回码等，让大家沟通有章可循。
安全怎么办？（安全规范）：规定好用户的密码必须加密存储，防止SQL注入、XSS 攻击等常见的网络安全问题。

架构师需要确保每个环节都符合规范，保证最终交付的“大楼”质量过硬。

职责四：解难题 —— 核心技术攻关的先锋

在盖楼的过程中，总会遇到一些意想不到的难题。比如，挖地基的时候发现了一块巨石，普通挖掘机搞不定。

在软件开发中也一样，当团队遇到一个极其棘手的技术难题，比如一个隐藏很深的性能瓶颈，一个复杂的分布式事务问题，或者一次重大的线上系统故障，这时候，就轮到架构师出马了。

他们凭借自己深厚的技术功底和丰富的经验，去定位问题、分析根源，并提出解决方案。他们是团队里的“技术定海神神针”，是解决“疑难杂症”的顶级专家。

作为架构师，一定都是要从一线的程序员中选拔出来的，必须具备足够丰富的解决问题的能力，否则当团队遇到疑难杂症的时候，架构师靠什么服众？在技术团队中不能服众

职责五：看未来 —— 技术演进的领航员

大楼盖好了，不代表架构师的工作就结束了。他还要“看未来”。

这栋楼以后会不会住不下？（容量规划）：随着电商平台用户越来越多，交易量越来越大，现在的系统架构还能撑几年？需不需要提前扩容？或者引入新的技术来应对未来的增长？
有没有更好的“装修”方案？（技术演进）：技术世界日新月异，今天还很先进的技术，可能两三年后就落伍了。老王需要时刻保持学习，关注业界最新的技术趋势，比如现在火热的云原生、AI 技术等，思考如何将这些新技术引入到现有系统中，进行“现代化改造”，让系统保持活力，而不是慢慢变成一个谁也不敢动的“技术古董”。
消除“建筑垃圾”（技术债务管理）：在项目赶进度时，程序员们可能会用一些临时的、不规范的方法来“抄近道”，这些都会留下“技术债务”。时间久了，这些债务会让系统变得越来越臃肿、越来越脆弱。架构师需要规划和推动团队去偿还这些债务，对系统进行重构和优化。

一个优秀的架构师，不仅要能解决眼前的问题，更要能为系统的未来发展指明方向，带领团队走在正确的航线上。