单体系统时代
############

* Monolithic
* “单体” 这个名称，却是从微服务开始流行之后，才 “事后追认” 所形成的概念。


思维误区: 单体架构是落后的系统架构风格，最终会被微服务所取代。

.. note:: 进程间通讯：Inter-Process Communication，IPC。RPC 属于 IPC 的一种特例


.. note:: 当我们在讨论单体系统的缺陷的时候，必须基于软件的性能需求超过了单机，软件的开发人员规模明显超过了 “2 Pizza Teams” 范畴的前提下，这样才有讨论的价值。


单体系统::

    Monolith means composed all in one piece. 
    The Monolithic application describes a single-tiered software application 
        in which different components combined into a single program from a single platform.
    —— Monolithic Application，Wikipedia


    分层架构（Layered Architecture）
    横向扩展（Scale Horizontally）

优点::

    易于开发： 
        开发方式简单，IDE 支持好，方便运行和调试。
        功能都在单个程序内部，便于软件设计和开发规划。
    易于测试： 
        所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。
        没有各种复杂的服务调用关系，都是内部调用方便测试。
    易于部署： 
        只需要将打好的一个软件包发布到服务器即可。
        程序单一不存在分布式集群的复杂部署环境，降低了部署难度。
    易于水平伸缩： 
        只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序
        （当然也需要采取分发策略保证请求能有效地分发到新节点）。

缺点::

    维护成本大：
        当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。
        当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；
        并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
    持续交付周期长： 
        构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。
    新人培养周期长： 
        新成员了解背景、熟悉业务和配置环境的时间越来越长。
    技术选型成本高：
        单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
    可扩展性差： 
        随着功能的增加，垂直扩展的成本将会越来越大；
        而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。


缺点::

    1. 单体系统的真正缺陷实际上并不在于要如何拆分，而在于拆分之后，它会存在隔离与自治能力上的欠缺。
    2. 在单体架构中，有任一部分代码出现缺陷，过度消耗进程空间内的公共资源，那所造成的影响就是全局性的、难以隔离的
    3. 由于隔离能力的缺失，除了会带来难以阻断错误传播、不便于动态更新程序的问题，还会给带来难以技术异构等困难。
    4. 单体程序的缺点一开始不是特别明显，项目刚开始需求少，业务逻辑简单，写代码很爽
    5. 噩梦从业务迭代更新，系统日益庞大开始，软件维护和迭代更新有无尽的痛苦。

缺点::

    1. 系统间通常以 API 的形式互相访问，耦合紧密导致难以维护
    2. 各业务领域需要采用相同的技术栈，难以快速应用新技术
    3. 对系统的任何修改都必须整个系统一起重新部署 / 升级，运维成本高
    4. 在系统负载增加时，难以进行水平扩展
    5. 当系统中一处出现问题，会影响整个系统

从开发流程来看主要有以下表现::

    1. Git 仓库过于臃肿，代码合并遭遇更多冲突，分支混乱，难以管理
    2. Git 仓库臃肿进而导致构建速度变慢，失败频率增加，上线变得困难
    3. 臃肿的代码越来越难以理解，维护成本升高，从而需要更多的人力成本
    4. 代码之间耦合严重，经常遭遇 “拔出萝卜带出泥” 的窘境，简直让人抓狂
    5. 技术栈单一，阻碍技术创新，技术债务堆积
    6. 复杂的功能需要消耗更多的资源，导致服务器压力增大，启动速度变慢
    7. 由于某些原因引入的一些 bug，可能导致整个系统崩溃，系统稳定性无法满足要求
    8. 随着业务增长，服务访问量增加，需要不断增加服务实例数以满足业务增长的需求，无法实现按需扩展
    9. 各功能模块之间随意调用，数据可以任意访问，安全性受到很大挑战

从架构角度来看主要有以下表现::

    1. 功能模块之间耦合严重，导致代码越来越难以维护和扩展，进而使业务拓展变得困难
    2. 团队边界模糊，职责不清晰，一旦出现问题，经常出现互相 “甩锅” 的情况
    3. 随着业务的增长，数据库压力与日俱增，数据安全性变差，对数据库的相似操作可能出现在很多服务中











技术异构::

    马丁・福勒（Martin Fowler）提出的 9 个特征，技术异构就是其中之一。
    它的意思是说允许系统的每个模块，自由选择不一样的程序语言、不一样的编程框架等技术栈去实现。


一个需要权衡的问题::

    如果说共享同一进程获得简单、高效这些优势的代价，是损失了各个功能模块的自治、隔离能力，那这两者孰轻孰重呢？


微服务去代替单体系统的根本原因。我认为最根本的原因是：单体系统并不兼容 “Phoenix” 的特性

随着软件架构的不断演进，我们构建可靠系统的观念，开始从 “追求尽量不出错”，转变为了正视 “出错是必然”的。