http://ibeetl.com/assets/index.html-C3eJpk8x.js

1import{_ as i,c as e,b as l,o as a}from"./app-B8MQJI6s.js";const p="/assets/arc_man-pBIuE6sE.png",r={};function o(n,t){return a(),e("div",null,t[0]||(t[0]=[l('<p>通常人们把软件架构师比作建筑师，从而确软件架构师的的职责，软件架构师和建筑师的共同点</p><ul><li>因为单词都是architect。软件行业很多理念借鉴了建筑行业，包括软件架构师这个职位。</li><li>建筑师对建筑做顶层设计，架构师的职责之一也是对软件系统做顶层设计。</li><li>充分考虑到质量要求。建筑师考虑到建筑美观，结实，抗震。软件架构师考虑系统的高可用和故障可恢复等</li></ul><p>但是由于软件项目需求迭代快，质量要求变化也非常快，因此建筑师比喻软件架构师是完全错误的，软件架构师负责软件的整个生命周期，需要极快的迭代项目。比如随着用户量增长，而建筑师一旦设计好建筑，则几乎不需要改动，建筑的目标客户及其数量也不会更改。 错误的类比错误影响了软件系统架构和软件架构师对自身定位。导致一些普遍出现的现象</p><ul><li>架构师不愿意对系统进行持续改进。特别是质量的要求变化。</li><li>架构师不愿意亲临一线，认为架构完毕后就是程序员的职责。</li><li>架构师认为自己是一次性建造系统，而不是培育系统</li><li>技术架构师逐渐脱离系统实际情况，演变自己成业务架构师或者TL。</li></ul><p>我从25年的一线开发架构经验来看，我更觉得软件架构师更像一个厨师长，而不是建筑师。</p><ul><li>厨师长同样会顶层设计，比如从购菜，配菜，切菜，以及炒菜各个环节来交付菜品。炒菜的菜品来源，调料和火候也是厨师长负责制定。</li><li>厨师和小工都能按照菜品配置炒菜，厨师长会亲自炒菜，主要一些关键菜品必须有厨师长负责</li><li>厨师长能灵活应对客户口味需求变化</li><li>厨师长是交付菜品的关键职位，是一个饭店口碑的关键。更换厨师长犹如更换了一个饭店。</li><li>厨师长与团队紧密合作</li></ul><p><img src="'+p+'" alt=""></p><p>总的来说，软甲架构师对于整个公司来说，应该是如下一个角色定位</p><ul><li>业务领域专家, 软件架构师需要熟悉业务流程，业务数据，了解业务的背景。在业务实现细节上，甚至比业务架构师还了解。</li><li>根据业务架构，实现后续的应用架构，数据架构，软件架构和物理架构</li><li>双驱动：架构风格和软件质量驱动软件实现。 架构师 应该关注业务架构，应用架构的质量要求，能主动捕获这些质量的需求并予以设计和实现。</li><li>数据专家，掌握数据模型和数据分布，数据是企业的重要资产。无论是传统应用，还是互联网，物联网</li><li>系统专家，熟悉系统的历史发展，系统的不足，系统的未来规划</li><li>技术专家，技术深度和宽度具备，并能跟踪和掌握流行技术</li><li>培育系统而不是一次性构建系统</li><li>架构师应该比团队更熟练与其他系统的接口和协议</li><li>其他团队的良好互动。包括业务团队，数据团队，运维团队，基础设施团队，测试团队，其他软件研发团队</li><li>作为丰富经验的开发者，负责软件架构中开发架构的完善，业务核心代码的完善。尤其是跟质量相关的代码。</li><li>作为开发者，参与研发和运维以获得系统运行的真实反馈</li></ul><p>在团队内部，架构师应作为一个有权威的开发工程师，应该具备的通常品质。</p><ul><li><p>领导力: 同团队共同制定愿景，并带领团队实现此愿景</p></li><li><p>影响力: 以他人乐于接受的方式，改变其思想和行动的能力。比如经常性挑战团队成员，指出万一系统或者周边系统出现问题下，团队应该如何做。</p></li><li><p>导师：不是教团队和个人如何做，而是引导团队和个人去做。</p></li><li><p>

1沟通者: 与团队每个人沟通，团队每个人乐意与你沟通，团队外的人有乐意与你沟通</p></li><li><p>用于承担责任：对于系统的表现不良好，不能完全归咎于团队实施，应该多反思是否是软件架构的问题。比如团队通常需要超出预估时间交付系统，是不是架构出了问题。</p></li></ul><p>这里分享几个对软件架构师职责把握不清楚导致的问题。来源于个人的经历</p><p><strong>故事一： 所有人都忽略了软件质量。</strong></p><p>一个传统企业，当转向数字化时候，业务架构和技术架构都非常重视业务流程，而忽略了其软件质量，比如业务提出系统能承担1000万的设备连接。但忽略了如果系统故障恢复情况下，1000万设备掉线后需要多长时间恢复正常。</p><p>这个质量需求长期被忽略直到当在线设备真的具备千万级别，在陆续发生了几次断网，千万设备蜂拥而入而导致网关系统崩溃，同时也导致其下游中小系统崩溃。此时只能紧急采取限流，逐步恢复时间超过了8小时以上。用户大量投诉。</p><p>再我们分析其有没有改进措施的时候，发现设备连接物联网是个重量级协议，不仅仅需要SSL连接，后续还有数条连接协议，比如安全认证，信息上报，上次失败原因上报。如果当初考虑到故障快速恢复这个需求，肯定会简化连接协议，让其变得轻量级。或者技术上调整架构， 把其他连接协议的处理，转交交给Kafka后，有专门的微服务异步处理。</p><p><strong>故事二：无架构风格的系统</strong></p><p>一个团队完成的系统非常简单，接受APP的调用，并转发到相应系统。这是一个简单的WEB系统，没有任何架构风格。后来需要有所变化，因为为了第三方测试，并不需要做真的转发。因此团队决定从当前系统fork出一个系统作为测试系统，删除掉转发代码并部署成一个新的服务。悲伤的故事来了，俩个系统都需要同步迭代新需求，但测试系统不受重视，尽管工作量并不小，复杂性同原有系统一样。这个测试系统曾经先后干跑了俩个工程师。他们都是不愿意无脑从原有系统复制代码（合并代码），其工作又不受到重视。</p><p>在我分析这个系统后，认为完全可以用一个系统完成，比如使用管道风格，对于正常的业务系统，调用的是一个管道，对于测试需求，调用的是另外一个管道，就像ZK的实现一样，ZK的主、从。观察节点 ，以及Standalone 这4种运行模式，都采用了不同的管道实现而代码只有一份。</p><p><strong>故事三：每年额外耗费200万的Redis集群</strong></p><p>软件架构师不仅仅是业务专家和数据专家，而且必须是技术专家，有一个团队，对用户提供设备的数字模型，即设备上报的属性和告警，以及设备当时允许的操作列表（比如待机情况下，不允许调整温度），以JSON形式返回。由于数字模型计算是个耗时的操作，大概响应时间250毫秒。 其他团队非常不满意。希望能在50毫秒内实现。</p><p>当时团队技术负责人错误的认为可以使用缓存来实现，即设备每次上报属性和告警后，都计算一次并存入到Redis里。</p><p>这种方案的问题在于缓存通常适合读多写少情况，而设备上报的次数远远多过用户主动读取数字模型测试（比如3千万设备在线，但用户可能只有10万在线），也忽略了Redis集群并不适合存放大Key数据。在申请了一个1024分片的大型Redis集群后，以及数百个计算节点后，使用此架构方案，导致Redis集群一直处于繁忙告警状态，而响应时间只提高到100毫秒。</p><p>在我分析这个方案后，认为精力应该集中在优化生成数字模型的性能上，保证用户实时查询，实时生成数字模型并满足50毫秒响应时间，我和团队对其数字模型生成算法进行性能优化后，挖æŽ

1˜å‡º30+个性能优化点。这一切仅用了一个月，且只增加少量服务节点就完成了。</p>',24)]))}const s=i(r,[["render",o],["__file","index.html.vue"]]),m=JSON.parse('{"path":"/article/arc_man/","title":"一文说清软件架构师职责","lang":"en-US","frontmatter":{"title":"一文说清软件架构师职责","tags":["架构","新书"],"createTime":"2026/05/24 12:06:15","permalink":"/article/arc_man/","description":"通常人们把软件架构师比作建筑师，从而确软件架构师的的职责，软件架构师和建筑师的共同点 因为单词都是architect。软件行业很多理念借鉴了建筑行业，包括软件架构师这个职位。 建筑师对建筑做顶层设计，架构师的职责之一也是对软件系统做顶层设计。 充分考虑到质量要求。建筑师考虑到建筑美观，结实，抗震。软件架构师考虑系统的高可用和故障可恢复等 但是由于软件项...","head":[["meta",{"property":"og:url","content":"http://ibeetl.com/article/arc_man/"}],["meta",{"property":"og:site_name","content":"闲大赋"}],["meta",{"property":"og:title","content":"一文说清软件架构师职责"}],["meta",{"property":"og:description","content":"通常人们把软件架构师比作建筑师，从而确软件架构师的的职责，软件架构师和建筑师的共同点 因为单词都是architect。软件行业很多理念借鉴了建筑行业，包括软件架构师这个职位。 建筑师对建筑做顶层设计，架构师的职责之一也是对软件系统做顶层设计。 充分考虑到质量要求。建筑师考虑到建筑美观，结实，抗震。软件架构师考虑系统的高可用和故障可恢复等 但是由于软件项..."}],["meta",{"property":"og:type","content":"article"}],["meta",{"property":"og:locale","content":"en-US"}],["meta",{"property":"og:updated_time","content":"2026-06-03T03:53:17.000Z"}],["meta",{"property":"article:tag","content":"架构"}],["meta",{"property":"article:tag","content":"新书"}],["meta",{"property":"article:modified_time","content":"2026-06-03T03:53:17.000Z"}],["script",{"type":"application/ld+json"},"{\\"@context\\":\\"https://schema.org\\",\\"@type\\":\\"Article\\",\\"headline\\":\\"一文说清软件架构师职责\\",\\"image\\":[\\"\\"],\\"dateModified\\":\\"2026-06-03T03:53:17.000Z\\",\\"author\\":[]}"]]},"headers":[],"readingTime":{"minutes":7.97,"words":2390},"git":{"updatedTime":1780458797000,"contributors":[{"name":"lijiazhi","username":"lijiazhi","email":"[email protected]","commits":1,"avatar":"https://gravatar.com/avatar/1b5114831459724ad4acc394423b4b48ecfa4a7e0659fbe07a0ce5181a1050a7?d=retro"}]},"autoDesc":true,"filePathRelative":"article/架构/arc_man.md","categoryList":[{"id":"92a2b5","sort":10001,"name":"article"},{"id":"9a9aed","sort":10005,"name":"架构"}]}');export{s as comp,m as data};