IT架构：从单体到微服务与系统思维
架构的转变往往并非刻意规划，而是项目发展的自然结果。当一个团队无法再承担负载，且决策需持续多年时，开发者便自然而然地成长为架构师。菲利普·德尔加多是一位金融科技架构师，他在90年代初从系统维护起步；入职仅六个月后，他就全面接管了项目。这迫使他跳出即时需求的局限，专注于系统的长期演进。
高等教育为应对复杂性提供了基础：数学教会抽象思维——从概念到实现的跨越。尽管大学很少直接教授架构，但培养了系统化思考能力。麦康奈尔、GoF设计模式以及福勒关于重构和代码结构的著作，共同奠定了坚实的基础。
自2007年起举办的Highload++等技术会议，架起了理论与实践之间的桥梁——与不同技术栈的开发者交流，揭示了理想与现实之间的差距。
架构师在团队中的角色
架构师是一种协调角色，而不仅仅是一个头衔。上世纪90年代，首席架构师负责全局对齐；如今，更多是资深或主工程师——他们对整个系统负责，而非单一模块。
在卡处理或早期Yandex.Money这类复杂项目中，架构师需预判各种场景，在性能与领域约束之间取得平衡。真正的成就感来自看到生产系统经受住真实世界的压力考验。初创公司教会适应力，但许多项目最终未能上线。
核心挑战：
- 理论架构与实际需求之间的脱节。
- 在不推倒重来的前提下适应变化。
- 平衡速度与可扩展性。
架构师常面临重复性工作，且未必能完全委派。专注力至关重要：2小时理解上下文，3小时深入思考，有时甚至需要数天才能解决。
单体架构 vs 微服务：情境决定选择
单体与微服务的选择取决于项目阶段和团队协作状态。早期阶段，由一支紧密协作的小团队运作时，单体架构更合适。当需求冲突频繁、需独立部署时，微服务才真正体现价值。没有放之四海而皆准的答案——选择会随着复杂度提升而动态演变。
架构师必须理解实现细节：一张‘精美’的架构图若缺乏技术栈认知，终将失效。解决方案架构师可能不写代码，但软件架构师必须具备实战框架经验——以预见实施成本与风险。
架构师的核心技能与工具
系统思维通过实践不断打磨——从宏观视角观察系统，并多角度审视问题。享受责任与自主：你的决策将影响系统质量长达数年。
厌恶人员流动：代码越少，流程越重复。换项目难度大，高度依赖领域熟悉度。
中高级岗位必备技能：
- 在抽象层级间自由切换。
- 预测系统未来演进路径。
- 评估实现成本。
- 协调相互冲突的需求。
- 聚焦于复杂问题本身。
书籍优于视频：文字便于反复阅读，构建线性逻辑。视频适合演示代码，但难以支撑深度理解。
推荐阅读：培养架构思维
培养架构意识，推荐以下读物：
- 《哈利·波特与理性魔法》（尤德科夫斯基）——理性与概率思维。
- TRIZ系列书籍，如《幻想星辰下的一个月》。
- 《普罗米修斯悖论》（梅斯特哈齐）——批判性分析能力。
- 洛特曼的符号学著作。
- 《孙子兵法》搭配康拉德评注版。
这些作品训练的是超越技术限制的分析思维。
最重要的几点
- 架构的本质是管理复杂性，而非绘制图表。
- 从编码转向架构，源于责任的自然增长。
- 软件架构必须具备技术栈实战经验。
- 系统思维需通过实践与阅读持续提升。
- 单体还是微服务？根据项目情境做出判断。
— Editorial Team
暂无评论。