架构设计

前言 因进行 Golang 项目开发也有很长的一段时间。这里主要是对在项目结构上的设计做个记录。本文主要讲述在搭建项目框架时的一些设计和思考。主要思考点：什么样的项目结构才清晰易于使用？什么样的项目结

前言 遇到 MQ 的面试问题，基本无法摆脱经常会遇到的几个问题：MQ 解决什么问题？如何保证可靠投递？如何保证消息一致性？等等问题，以下将重点分析面对一致性的问题，在面试时应该如何回答会更有优势。 本

背景 某项目中有一个收费业务，生成订单，订单状态为待支付。在移动端上打开该功能时可查看到待支付的订单，然后用户可以对待支付的订单进行支付。但偶尔出现客户反馈支付后订单还是待支付的状态，导致用户无法继续

背景&目标 确保服务高可用的前提下， 降低后端服务的负载能力，对一些频繁读取的功能和复杂计算的的功能增加缓存，降低后端的负载 加快请求的响应时间，利用缓存优化数据读取，直接从缓存中读取比从 DB 中读

在很多系统上都会遇到日志类的需求，如记录用户的行为日志，记录浏览记录、操作记录等。审计日志就是日志需求中的一种，也成为审计跟踪，是对事件和更改的记录。通常都是将一系列的动作或特定的活动相关的事件进行记

众多对象之间的一对多关系是这种观察者模式的基础。 它使您能够设置订阅机制，允许其他实体在您订阅的实体上的每次事件时收到警报。Kafka、RabbitMQ、Amazon SNS 和 NATS 是实现发布

架构分层 架构分层是将软件模块按水平切分多个层级，即一个项目由多个模块组成，一个模块划分多个层级，每个层级处理不用的事情，有自己独立的职责。 三层架构 以前刚接触软件开发时，第一次接触的分层是三层/四

组件是部署的单元，组件可被作为系统一部分部署的最小项。良好设计的组件可以被独立的开发，独立的发布，独立的部署。 为了实现组件存在的目的，我们应该如何去实现？或者说怎么去设计组件？需要考虑哪些元素？

依赖倒置原则的定义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其核心思想是：要面向接口编程，不要面向实现编程。

接口隔离 接口隔离原则 Interface Segregation Principle，ISP 客户端不应该依赖它不需要的接口 类间的依赖关系应该建立在最小的接口上 我的理解，在定义接口时方法应该尽量

里氏替换 里氏替换原则 Liskov Substitution Principle，LSP 继承必须确保超类所拥有的性质在子类中仍然成立。 里氏替换原则，主要在阐述关于继承的一些原则。什么时候使用继承

开闭原则 开闭原则 Open Closed Principie ，OCP 软件实体的行为应当不是修改实体，而是对实体进行扩展。 比如，有一个财务报表系统，已实现了财务数据的滚动，且负数显示红色的。但工

架构设计原则主要作用是让我们明确如何在类中安排我们的程序和数据结构，以及这些类之间的关系应该如何建立。SOLID原则的目标是创建中层软件架构，满足：容忍改变、易于理解、基础组件可以用在多个软件系统中。

函数式编程 架构设计另一个编程范式—函数式编程，其主要关心数据到数据之间的映射关系，即将计算过程抽象描述成一种表达式求值。先看下以下实现数组转换成数组对象的函数代码： 定义变量，循环数组，把值开头大写

RPC RPC （Remote Process Call）远程过程调用。 单台服务器的处理能力受硬件成本限制，不可无限提升。由此，通过将原本的本地调用转变为调用远程服务器上的方法，使得系统的处理能力和

面向对象是通过使用多态性来获得对系统中每个源代码依赖的绝对控制的能力。它允许架构师创建一个插件架构，其中包含高层策略的模块独立于包含低层细节的模块。