Reference

Murphy’s Law: Anything that can go wrong will go wrong. 墨菲定律：凡事只要有可能出错，那就一定会出错。

Conway's law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. 康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构。

演进中的架构

架构并不是被“发明”出来的，而是持续进化的结果。

技术架构者的第一职责就是做决策权衡。

  • 单体架构（巨石系统 Monolithic Application）

    • 并非 "不可拆分 All in One Piece", 更多的是 "自给自足 Self-Contained"
    • 优点
      • 易于分层
      • 易于开发
      • 易于部署测试
      • 进程内调用简单高效
    • 缺点
      • 缺乏隔离与自治能力
        • 代码bug影响面广，轻则影响程序运行，重则波及机器（端口占用、连接池泄露）
      • 动态可维护性差
        • 无法单独停止、更新、升级某一部分

  • 服务拆分架构

    • 烟囱式架构 Information Silo Architecture
      • 应用间完全独立（数据库、服务器）
    • 微内核架构 Microkernel Architecture（插件式 Plug-in）
      • 可拓展、灵活、天然隔离
      • 插件模块间互不交互
    • 事件驱动架构 Event-Driven Architecture
      • 利用事件队列管道 Event Queues 解耦， 消费者相互独立但也可以利用管道互动

  • SOA架构 Service Oriented Architecture

    • 一套软件研发方法论
      • 有着明确的设计指导原则
      • SOAP远程调用协议
      • ESB企业服务总线消息管道 Enterprise Service Bus
      • ...
    • 给架构带来过度复杂性

  • 微服务架构 Microservices

    • 九个微服务系统的特征（非强制约束）
      1. 围绕业务能力构建（Organized around Business Capabilities）
        • 围绕着一个拥有完整业务能力的团队去构建程序，而非按技术划分团队（UI团队、DBA团队、业务开发团队）。
      2. 分散治理（Decentralized Governance）
        • 允许技术异构，用合适的技术栈完成业务
      3. 通过服务来实现独立自治的组件（Componentization via Services）
      4. 产品化思维（Products not Projects）
        • 把软件研发当成一种持续改进、提升的过程，为产品的整个生命周期负责
      5. 数据去中心化（Decentralized Data Management）
      6. 轻量级通讯机制（Smart Endpoints and Dumb Pipes）
        • 服务的功能不应使用复杂的通讯管道处理，由服务Endpoint自己解决
      7. 容错性设计（Design for Failure）
        • 可靠系统完全可以由容许出错的服务来组成
      8. 演进式设计（Evolutionary Design）
        • 承认服务会被报废淘汰
      9. 基础设施自动化（Infrastructure Automation）
    • 虚拟化与容器化技术发展贡献巨大
      • Kubernetes 等基础设施提供的服务颗粒度相对较粗（针对容器做整体管理），无法满足细粒度的额外需求，如根据流量特诊、机器负载等的负载均衡
      • 边车代理模式 Side-car Proxy
        • 注入通讯代理服务器，为控制平面通讯带来细粒度的管理能力

  • 无服务架构 Serverless

    • 以 AWS 的 Lambda 服务为代表 （Faas，Function as a Service）
    • 开发者只需关注业务
    • 冷启动、无状态等特点，决定它不具有普适性