大伙还好, 我身为技术领域的老梁, 眼下呈现的乃是此系列文章当中的第二篇。热忱欢迎大伙去展开讨论, 踊跃分享自身所拥有的经验。要是那些知识对于你而言存有实用价值的, 那就请关注我, 给予老梁诸多方面的支持, 以此激励我去分享质量更为突出的内容。朝着读者而言: 已然具备独自去交付, Boot加上Vue或者React项目潜能, 预备去打通从前端到后端再到云的任督二脉的全栈工程师。于我的开发生涯历程之时, 历经过从单体应用朝着微服务的转变, 从起始的加上JSP到现今的加上Vue3, 从传统部署迈向云原生的完备演进进程。当下, 我打算摒弃那些徒有其表的理论, 去分享一些确确实实经历过实战检验的架构设计经验。一、为什么从写代码转向架构思维在业务快速迭代的早期我们关注的是功能交付AI的出现让这种交付更快速、简单。流量膨胀之际, 团队也跟着膨胀起来, 需求复杂度同样处于膨胀状态, 此时, 不管是前端还是后端, 痛点从“怎么写”转化为:此时架构设计能力成为区分中级与高级全栈工程师的分水岭。二、思维三层楼楼层思考焦点典型误区我的土办法地基 系统思维整个系统如何活过度设计每季度画一次系统生存图节点生命线骨架 业务思维业务到底想赢什么技术自嗨把 OKR 翻译成技术假设贴在显示器表皮 工程思维今天怎么安全落地完美主义用可回滚 替代评审 PPT三、针对架构设计的四维视图维度关注点, 从“战术”层面转变至“战略”层面, 存在着可落地的工具或是方法, 有这样的情况, 逗号, 有那样情形。业务领域模型、业务流程DDD、事件风暴技术组件、框架、中间件选型技术雷达、ADR数据数据一致性、容量规划CQRS、分库分表组织团队边界、协作节奏康威定律、先让业务赢再让系统活最后让自己睡得着。倘若我们开发出的这个系统最终面对于此的用户, 而该用户体验情况欠佳, 又或者频繁地在需求以及评审之间徘徊不定, 那么就需要针对地基是否坚固加以考量。四、 全局观的四张图, 其中一张叫业务流图, 也就是Flow Map, 还有一张是技术切面图, 即Slice Map, 另外一张为风险热力图, 是Risk Heat Map, 最后一张是成本收益图, 称作ROI Map四、云原生时代的“5 2”技术栈层级组件的选型理由。网关Cloud原生响应式支持服务Boot 3.x 原生镜像启动数据 -Flex复杂查询友好、轻量缓存Redis 分布式锁、限流、布隆过滤器消息Kafka Cloud高吞吐、幂等生产观测 Loki指标、日志、链路三位一体部署 Argo CD声明式交付能云不地能原不虚能边不中。五、演进式架构让变化成为常态5.1 架构演进三阶段单体模块化分布式服务函数FaaS5.2 演进驱动指标指标目标值监控手段平均交付周期Jira Cycle Time部署频率10次/天Argo CDMTTR架构腐化率 Sonar六. 出现故障的叙事具有两则内容, 一则名为6.1一个日志字段引发的P1 , 另有一则是6.2对前端版本回滚的7分钟的记录。最后, 针对年轻工程师给出几条建议, 其一为不要盲目去追求新技术, 因为稳定性和可维护性相较于新技术更为重要其二是需要深入去理解业务, 即好的架构师首先乃是专注于某些专门事务的行家其三是要保持简单, 原因在于最简单的那种方案通常是最为有效的其四主张量力而行, 也就是要挑选团队能够把控的技术栈其五强调持续学习, 鉴于技术更新速度极快, 然而要分辨出哪些是真正具备价值的, 还有结语内容以及下集预告。编写程序乃是一场永远不会有尽头的修炼。这些日子以来, 我最为深刻的感受是: 最为出色的产品并非是通过设计所造就的, 而是经由演进所产生的。在面对繁杂系统的时候, 我们需要秉持敬畏的心态, 不能够只是一味地大胆创新。临近的下一篇文章《从单体到云原生的演进脉络》, 将会去介绍历经近20年时间的Java前后端框架的5大演变过程, 并且会给出相关实践经验。敬请期待