weixin_39757802的博客

试想某个场景，某开发团队老大在review大家代码的时候，察觉到一个严重的问题：发现码农张三李四王五三人写的各子系统的代码有些是重复的，都在重复造轮子，于是老大从整个系统软件架构的宏观角度看这些代码，发现了太多的重复和冗余，既缺乏模块化的设计，又没有扩展性、复用性和维护性方面的考量。具体的设备驱动程序实现了 my_net_device_operations 结构体中的方法，并通过 netdev_priv() 函数获取设备私有的数据结构 my_net_device，然后调用相应的设备操作方法。

在当今互联网时代，分布式系统架构成为推动现代软件开发和服务部署的核心理念。分布式系统在解决单点故障、提高系统可扩展性和确保高可用性方面发挥着至关重要的作用。

●前端架构主要关注用户界面和用户体验，负责处理用户与应用程序交互的所有事项，包括页面渲染、用户输入相应、前端逻辑和交互设计等。后端架构主要处理应用程序的业务逻辑、数据存储、安全性、性能优化等方面，后端通常包括数据存储、服务器端逻辑、API 设计等。●前端架构主要使用 HTML、CSS、JavaScript 等技术构建用户界面，常见的前端框架有 React、Vue 等。

这是一个现在很多大厂前些年开始出现的一个职位 Title，这对人的要求其实会更宽广一些，不仅要懂业务、懂行业、懂技术，还要懂分析定位问题、结合问题和自家服务给出对应的解决方案，然后也要跟踪项目执行过程、协调资源、注重成本，姑且称之为“六边形战士”类型的架构师吧。成为架构师的前提是你必须是一位程序员的出身，并且必须一直坚持做一线程序员，有自己的总结提炼成长，有自己的专精领域和富足的视野，没有一个架构师是没有写过代码的。优秀的沟通技能，包括倾听、口头/书面沟通、推进、冲突管理等，能够在各个层面进行高效的沟通。

对计算机系统的某一部分加速的时候，Amdahl 阿姆达尔定律提醒我们，当优化系统中的某一部分时，应该关注那些对整体性能有明显影响的部分。架构遵循定律是我们在设计和演进软件系统时可以借鉴的一系列原则和规律，这些定律包括但不限于康威定律、梅特卡夫定律、布鲁克斯定律等，它们提供了一些建议和准则，帮助我们更好地理解和规划架构的演进。康威定律认为组织和系统结构之间存在异质同态特性，即组织的沟通结构会在系统结构中得以映射，这意味着构建系统时，要考虑到团队的组织结构，以避免不必要的复杂性。

物理架构图显示系统在物理硬件上的部署，而运维架构图展示了系统的运维结构和流程，包括监控、日志、自动化运维等。架构可视化在软件开发中扮演着至关重要的角色，它不仅使团队成员和协作部门更容易理解系统架构，提高协作效率，还有助于开发者迅速发现问题和瓶颈，以便及时采取优化措施。链路依赖图是系统中模块、组件或系统之间的关系图，帮助理解系统的组成和功能，以及它们之间的关系。在具体实践中，通过追踪代码结构、检查冗余代码和查看拓扑结构等方式，来确定系统的复杂性，然后进行相应的优化。这有助于提高系统的容错性、可用性和性能。

然而，对于简单的应用程序，引入 CQRS 可能会增加不必要的复杂性。记住，架构设计没有银弹，选择最适合您的项目和团队的架构才是最为关键的，让我们通过不断学习和实践，积累更丰富的架构经验，不断提升自己的架构设计水平，推动团队和组织朝着更稳健、可维护、可扩展的方向发展，同时在这个实践过程中不断提升我们的架构技能。在软件架构的领域中，我们介绍了多种经典架构模式，每一种都为解决特定问题和满足不同需求提供了独特的视角和解决方案，旨在帮助大家理解不同架构设计风格的适用场景，为未来的项目开发提供丰富的选择。

同时，通过团队的不断学习、迭代和有效的沟通，可以更好地适应业务和技术的变化，确保软件系统的长期健康。基于对 REP 、 CCP 、 CRP 三个原则的理解，会发现这三个原则之间彼此存在着竞争的关系：REP 和 CCP 是黏合性的原则，基于这两个原则会让组件变得更大，但 CRP 原则是建议拆分原则，会尽量让组件变小，三者共存，如何取舍？提高可维护性：通过组件聚合，将相关联的组件放在一起，可以减少代码的耦合度，提高代码的可维护性，当需要修改某个组件时，可以避免在其他模块中查找和修改代码，降低出错的风险。

更好的可重用性：通过使用合成/聚合，可以根据需要组合不同的对象来实现代码的可重用性，且合成/聚合本身是一种松耦合，可以更便捷地组装新的对象类型。是一项简单易懂且重要的原则，但是在实 际过程中往往最容易忽略的，它强调在应用中，一个类应该只有一个引起变化的原因，只有一个职责。更好的可扩展性：通过使用合成/聚合，更便捷地添加新的功能和行为到应用中，这种灵活的关系，可以更容易适应新的需求和变化。提高代码的可维护性和可重用性：允许系统通过扩展已有的代码来应对新的需求，而不是修改已有的代码，降低引入错误的风险。

为了解决这一问题，基础设施进行了第二次演进，即服务网格（Service Mesh）的边车代理模式（Sidecar Proxy），边车即在基础设施中由系统自动地在服务的资源容器（比如 Kubernetes 中的 prod）中注入一个通信代理服务器，用类似网络安全里中间人攻击的方式进行流量劫持，在应用无感知的情况下，接管应用所有对外通信。由于硬件限制，将系统拆分到不同的机器上引发了一系列的问题，包括服务发现、跟踪、通讯、容错、隔离、配置、传输、数据一致性和编码复杂度等多方面的挑战。

使用最小的人力成本、最高的质量、更高的客户满意度来满足构建和维护该系统的需求。同时，还需要在架构的设计和实现过程中，注重成本效益、可维护性、可扩展性等方面的考虑，以确保系统能够以最低的成本、最高的质量和客户满意度来满足用户的需求。架构需要将不变的部分从变化中抽象出来，沉淀为稳定的组件，同时管理多个组件之间的依赖，识别、定位、管理组件的边界和上下文，让变化更容易暴露和识别。总之，好的系统架构需要在满足用户需求的同时，注重成本效益、稳定性和可扩展性等方面的考虑，以实现系统的长期稳定和适应变化。

通过深度了解这九大核心架构模式，我们将能够更好地选择和应用适合特定项目的架构，从而构建出既美观又高效的软件系统。让我们一同探索软件设计中的这些美妙之旅，挖掘架构之美的深层次内涵。

工厂模式（Factory Pattern）  抽象工厂模式（Abstract Factory Pattern）单例模式（Singleton Pattern）建造者模式（Builder Pattern）原型模式（Prototype Pattern）-----------------------------------------------------------------适配器模式（Adapte...