通常人们把软件架构师比作建筑师，从而确软件架构师的的职责，软件架构师和建筑师的共同点

• 因为单词都是architect。软件行业很多理念借鉴了建筑行业，包括软件架构师这个职位。
• 建筑师对建筑做顶层设计，架构师的职责之一也是对软件系统做顶层设计。
• 充分考虑到质量要求。建筑师考虑到建筑美观，结实，抗震。软件架构师考虑系统的高可用和故障可恢复等

但是由于软件项目需求迭代快，质量要求变化也非常快，因此建筑师比喻软件架构师是完全错误的，软件架构师负责软件的整个生命周期，需要极快的迭代项目。比如随着用户量增长，而建筑师一旦设计好建筑，则几乎不需要改动，建筑的目标客户及其数量也不会更改。 错误的类比错误影响了软件系统架构和软件架构师对自身定位。导致一些普遍出现的现象

• 架构师不愿意对系统进行持续改进。特别是质量的要求变化。
• 架构师不愿意亲临一线，认为架构完毕后就是程序员的职责。
• 架构师认为自己是一次性建造系统，而不是培育系统
• 技术架构师逐渐脱离系统实际情况，演变自己成业务架构师或者TL。

我从25年的一线开发架构经验来看，我更觉得软件架构师更像一个厨师长，而不是建筑师。

• 厨师长同样会顶层设计，比如从购菜，配菜，切菜，以及炒菜各个环节来交付菜品。炒菜的菜品来源，调料和火候也是厨师长负责制定。
• 厨师和小工都能按照菜品配置炒菜，厨师长会亲自炒菜，主要一些关键菜品必须有厨师长负责
• 厨师长能灵活应对客户口味需求变化
• 厨师长是交付菜品的关键职位，是一个饭店口碑的关键。更换厨师长犹如更换了一个饭店。
• 厨师长与团队紧密合作

总的来说，软甲架构师对于整个公司来说，应该是如下一个角色定位

• 业务领域专家, 软件架构师需要熟悉业务流程，业务数据，了解业务的背景。在业务实现细节上，甚至比业务架构师还了解。
• 根据业务架构，实现后续的应用架构，数据架构，软件架构和物理架构
• 双驱动：架构风格和软件质量驱动软件实现。 架构师 应该关注业务架构，应用架构的质量要求，能主动捕获这些质量的需求并予以设计和实现。
• 数据专家，掌握数据模型和数据分布，数据是企业的重要资产。无论是传统应用，还是互联网，物联网
• 系统专家，熟悉系统的历史发展，系统的不足，系统的未来规划
• 技术专家，技术深度和宽度具备，并能跟踪和掌握流行技术
• 培育系统而不是一次性构建系统
• 架构师应该比团队更熟练与其他系统的接口和协议
• 其他团队的良好互动。包括业务团队，数据团队，运维团队，基础设施团队，测试团队，其他软件研发团队
• 作为丰富经验的开发者，负责软件架构中开发架构的完善，业务核心代码的完善。尤其是跟质量相关的代码。
• 作为开发者，参与研发和运维以获得系统运行的真实反馈

在团队内部，架构师应作为一个有权威的开发工程师，应该具备的通常品质。

• 领导力: 同团队共同制定愿景，并带领团队实现此愿景

• 影响力: 以他人乐于接受的方式，改变其思想和行动的能力。比如经常性挑战团队成员，指出万一系统或者周边系统出现问题下，团队应该如何做。

• 导师：不是教团队和个人如何做，而是引导团队和个人去做。

• 沟通者: 与团队每个人沟通，团队每个人乐意与你沟通，团队外的人有乐意与你沟通

• 用于承担责任：对于系统的表现不良好，不能完全归咎于团队实施，应该多反思是否是软件架构的问题。比如团队通常需要超出预估时间交付系统，是不是架构出了问题。

这里分享几个对软件架构师职责把握不清楚导致的问题。来源于个人的经历

故事一： 所有人都忽略了软件质量。

一个传统企业，当转向数字化时候，业务架构和技术架构都非常重视业务流程，而忽略了其软件质量，比如业务提出系统能承担1000万的设备连接。但忽略了如果系统故障恢复情况下，1000万设备掉线后需要多长时间恢复正常。

这个质量需求长期被忽略直到当在线设备真的具备千万级别，在陆续发生了几次断网，千万设备蜂拥而入而导致网关系统崩溃，同时也导致其下游中小系统崩溃。此时只能紧急采取限流，逐步恢复时间超过了8小时以上。用户大量投诉。

再我们分析其有没有改进措施的时候，发现设备连接物联网是个重量级协议，不仅仅需要SSL连接，后续还有数条连接协议，比如安全认证，信息上报，上次失败原因上报。如果当初考虑到故障快速恢复这个需求，肯定会简化连接协议，让其变得轻量级。或者技术上调整架构， 把其他连接协议的处理，转交交给Kafka后，有专门的微服务异步处理。

故事二：无架构风格的系统

一个团队完成的系统非常简单，接受APP的调用，并转发到相应系统。这是一个简单的WEB系统，没有任何架构风格。后来需要有所变化，因为为了第三方测试，并不需要做真的转发。因此团队决定从当前系统fork出一个系统作为测试系统，删除掉转发代码并部署成一个新的服务。悲伤的故事来了，俩个系统都需要同步迭代新需求，但测试系统不受重视，尽管工作量并不小，复杂性同原有系统一样。这个测试系统曾经先后干跑了俩个工程师。他们都是不愿意无脑从原有系统复制代码（合并代码），其工作又不受到重视。

在我分析这个系统后，认为完全可以用一个系统完成，比如使用管道风格，对于正常的业务系统，调用的是一个管道，对于测试需求，调用的是另外一个管道，就像ZK的实现一样，ZK的主、从。观察节点 ，以及Standalone 这4种运行模式，都采用了不同的管道实现而代码只有一份。

故事三：每年额外耗费200万的Redis集群

软件架构师不仅仅是业务专家和数据专家，而且必须是技术专家，有一个团队，对用户提供设备的数字模型，即设备上报的属性和告警，以及设备当时允许的操作列表（比如待机情况下，不允许调整温度），以JSON形式返回。由于数字模型计算是个耗时的操作，大概响应时间250毫秒。 其他团队非常不满意。希望能在50毫秒内实现。

当时团队技术负责人错误的认为可以使用缓存来实现，即设备每次上报属性和告警后，都计算一次并存入到Redis里。

这种方案的问题在于缓存通常适合读多写少情况，而设备上报的次数远远多过用户主动读取数字模型测试（比如3千万设备在线，但用户可能只有10万在线），也忽略了Redis集群并不适合存放大Key数据。在申请了一个1024分片的大型Redis集群后，以及数百个计算节点后，使用此架构方案，导致Redis集群一直处于繁忙告警状态，而响应时间只提高到100毫秒。

在我分析这个方案后，认为精力应该集中在优化生成数字模型的性能上，保证用户实时查询，实时生成数字模型并满足50毫秒响应时间，我和团队对其数字模型生成算法进行性能优化后，挖掘出30+个性能优化点。这一切仅用了一个月，且只增加少量服务节点就完成了。