MVC 是最古老的模式可追溯到近 50 年前。每个模式都有一个 “视图”V负责显示内容和接收用户输入也就是我们常说的前端本质是呈现数据给用户一个交互的接口。大多数模式都包含一个 “模型”M用于管理业务数据“控制器”、和“演示器 “ 是视图和模型之间的翻译器。抽象工厂将创建和外观分开原型制作示例的副本单例只有一个实例的特殊类。适配器可连接不同接口的插头桥梁: 将对象的工作方式与功能联系起来合成由简单和复杂部件组成树形结构装饰器在不改变对象核心下为其添加功能。门面简化的单一界面代表整个系统Flyweight分享可重复使用的小物品代理代表另一个对象访问/操作责任链对象链传递请求直至处理完毕命令将请求转化为对象随时可执行操作逐个访问集合中的元素调解器通信枢纽 - 简化不同类之间的交互记忆捕捉并恢复对象的状态观察者: 通知类其他对象的变化访客: 在不改变类别下添加新的操作如何设计 Stack Overflow 网站面试官可能希望看到类似图片上半部分的内容。微服务用于将系统分解成小的组件。每个服务都有自己的数据库。大量使用缓存。服务是分片的。服务之间通过消息队列进行异步对话。该服务是利用 CQRS 的事件源功能实现的。展示分布式系统知识如最终一致性、CAP 定理等。实际上——Stack Overflow 仅使用 9 台内部网络服务器为所有流量提供服务而且是单体服务器它有自己的服务器不在云上运行。“大道至简”Monorepo 并不新鲜; Linux 和 Windows 都是使用 Monorepo 创建的。为了提高可扩展性和构建速度谷歌开发了内部专用工具链以加快扩展速度并制定了严格的编码质量标准以保持一致性。亚马逊和 Netflix 是微服务理念的主要倡导者。Microrepo 方法自然而然地将服务代码分离到不同的资源库中。它的扩展速度更快但可能会导致日后的治理痛点。在 Monorepo 中每个服务都是一个文件夹每个文件夹都有 BUILD 配置和 OWNERS 权限控制。每个服务成员负责自己的文件夹。依赖关系在整个代码库中共享与业务无关因此当版本升级时每个代码库都会升级自己的版本。在 Microrepo 中每个服务负责自己的版本库通常为整个版本库设置构建配置和权限。依赖关系受控于每个版本库。企业可根据自己的时间表选择何时升级版本。Monorepo 有一个签到标准。谷歌的代码审查流程以设置高标准而闻名确保 Monorepo 的质量标准一致无论业务如何。谷歌工程师开发了 BazelMeta 开发了 Buck。还有其他开源工具包括 Nix、Lerna 等。Microrepo 既可以制定自己的标准也可以通过采纳最佳实践来采用共享标准。它可以更快地扩展业务但代码质量可能会有些不同。多年来Microrepo 支持的工具越来越多包括 Java 的 Maven 和 Gradle、NodeJS 的 NPM 和 C/C 的 CMake 等等。