聊完DevOps需求领域的实践，我们进入DevOps开发篇。软件研发流程大致可分为 需求、开发、测试、发布、线上运维 五个阶段，DevOps的CI/CD领域的实践贯穿始终！
业务目标明确，产品整体方案确定，用户故事地图绘出，之后的实施落地之路也并非一帆风顺的。为了保持软件交付质量和效率的可持续性，我们往往需要卓越的架构设计，包括业务架构和软件工程的架构。
DevOps的模型中其实对架构的描述并不很系统全面，个人理解也还在持续发展完善中。在介绍DevOps的架构实践之前，我们来看看可以说比整个DevOps实践体系还丰富多彩的软件架构方法论。
之前我们说过，了解一个方案论，我们推荐“Why - How - What”的黄金圈法则。今天我们仍然尝试，从这三个层面说下软件架构的Why、How、What。这时候确实需要说一句，因本人水平和时间有限，难免有不妥之处，敬请谅解！
++软件架构的Why++
在《Google软件工程》^[1]^一书中，开篇就指出了软件工程的三个要素：时间、规模和权衡。软件工程师被要求做出复杂且高风险的决策，通常是基于对时间和增长的不精确估计。
软件架构考虑的因素大抵也是如此，软件架构也是为了对抗由于时间、规模、不确定性带来的软件复杂度，好的架构就是要控制由于时间、规模等带来的高复杂度，让后续软件系统迭代过程不至于举步维艰、如履薄冰，以便可以持续带来业务价值，提高生产力，保障质量和效率。
++软件架构的How++
软件架构并没有一个标准的、被普遍接受的权威定义。在《从0开始学架构》专栏^[2]^中，李运华老师给出的定义是：软件架构指软件系统的顶层（Rank）结构，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规则（Rule）。
总之，软件架构蕴含着一系列的决策，需要我们遵守一系列的原则[3]，包括
1、简单原则（KISS）、DRY、YAGNI 等架构原则；
2、面向对象等范式、SOLID五大原则的整洁架构之道。
不只如此，《郭东白的架构课》中提出的架构师六大生存法则 - 目标、人性、价值、技术、文化等，业界提出的三高（高可用、高性能、高并发）架构，还有可伸缩、可扩展、可维护、可持续性等等。
++软件架构的What++
What代表着具体实践。软件架构发展几十年以来一直在不断演进，从原始分布式、单体到SOA，再到微服务、云原生架构、ServiceMesh到无服务Serverless，软件架构一直在发展^[5]^。
这里面用的方法、技术、框架和产品更是日新月异，微服务与DDD的结合堪称经典，微服务的服务注册与发现、网关、限流熔断组件、可观测性组件相关的产品多到眼花缭乱，Springboot、Kratos等各种语言的服务框架也是层出不穷。关于支持高可用、高性能、高并发的具体实现，也有Redis、Kafka等一系列的优秀产品和配套实践。
++DevOps视角的架构++
DevOps更关注软件交付的可持续性，关注交付过程中的协作效率，关注交付的质量和效率。在Dora的DevOps Core Model^[6]^中重点列举了 代码可维护性、松耦合架构、监控和可观测性 这三个软件架构领域也在普遍关注的优秀实践。
在这个实践体系的指导下，让系统和工具使开发人员可以轻松地更改由其他人维护的代码；松耦合架构也让团队能够按需测试和部署应用程序，而不需要与其他服务进行编排，拥有松散耦合的体系结构允许团队独立工作，而不依赖于其他团队的支持和服务，这反过来也能够快速工作并为组织提供价值；完善的监控和可观测性体系让团队更容易发现和快速解决线上问题。
架构需要持续演进，DevOps实践中，代码可维护性、松耦合架构、监控和可观测性的建设可以先行！
参考：
[1] https://book.douban.com/subject/35838155/
[2] https://time.geekbang.org/column/intro/100006601
[3] https://book.douban.com/subject/30333919/
[4] https://time.geekbang.org/column/intro/100099801
[5] https://book.douban.com/subject/35492898/
[6] https://dora.dev/research/