神话
曾经刚入行时，以为架构师就是负责技术选型
到底是用mysql还是oracle，用redis还是memcached，用hibernate还是mybatis
毕竟，只有熟练使用过这些框架的人，才能从中挑选出最适合当前项目的
神话破碎
后来才发现，其实哪有那么多有丰厚无比的项目经验的人，很多也都是赶鸭子上架
临时写几个demo，通过网上各种资料紧急研究一下
选择一个看起来貌似比较靠谱的选择，然后摸着石头过河
认知颠覆
再后来，才发现，架构师怎么可能仅仅只是负责技术选型，那只是冰山一角
要考虑的因素太多了，需求，性能，安全，成本，人力，团队，发展，风险，规范
仿佛每个词都能成为大学一个学期的必修课程
重塑认知
在自己也慢慢开始接触架构设计后，发现架构师又重新可以归纳为2大职责
技术选型和模块划分
而此时的技术选型也不再是当初那个简单的概念，而是一整套技术方案
模块划分也不仅仅是字面上简单的划分模块，而是一整套需求解决方案
架构师需要给出两套互相适配，互相支撑，互相促进的技术与需求方案
如果以造房子作对比，那么技术选型就像是建材的选取，而模块划分就像是房屋结构的设计
同样是架构师，可能有的只能在农村设计一个小平房，而有的可以设计摩天大厦，天差地别
当然，摩天大厦也未必是一人设计，也有可能是一整个架构师团队
举个例子
以前面提到的技术方案为例，如今AI爆火，那么我们的项目中是否需要引入AI？
AI回答可能有幻觉，不稳定，给人的感觉是胡编乱造
当前系统强调准确性，真实性，稳定性，不太合适？
领导重视，所以还是决定引入，那如何解决AI幻觉？
开源框架一堆，使用底层机器学习框架还是更上层的AI应用开发框架？
没精力做底层研发，或者没有大模型相关人才，只能用上层应用开发框架，那使用spring-ai还是langchain？
langchain更成熟，开源的支持更多，用langchain？
那当前项目组人员都是java怎么办，招人做python？
AI相关人才当前市场价太高，承担不起？python性能太差，与项目要求不符？
需求，性能，安全，成本，人力，团队，发展，风险，规范，一条条一件件都穿插在技术选型的过程中，需要架构师全方位综合考虑，衡量利弊做出取舍
模块划分也是一样，要不要分层，要不要划分微服务？
划分微服务的话，需求层面应该划分多少微服务？
实际人力资源又支持划分多少微服务？
划分后能否适应需求的快速增长？
微服务直接如何进行通信，如何保证事务
假设需求边界扩展，未来如何进行技术演进
假设业务量暴增，如何进行扩容
如何确保生产安全，如何设计容灾备份和故障转移
有时候架构师还会承担一些项目经理或技术总监的职责，例如需求开发测试的整体流程规划，项目进度把控，跨团队的沟通协调，指定技术标准和开发规范，团队技术能力建设等
总之，架构师并不是一个技术等级，而是一类特殊的技术岗位，能力可高可低，职责可大可小，一切全看个人的努力与积累