《凤凰架构》摘记

目录

一、服务架构演进史

1.1原始分布式时代

1.2单体系统时代

---

一、服务架构演进史

        架构不是被凭空发明出来的，而是一个持续演进的结果

1.1原始分布式时代

       Open Software Foudation 邀请 业界主流计算机厂商一起参与，制定了 Distributed Computing Environment；这是一套相对完整的分布式服务组件规范与参考实现，包括DEC/RPC、DCE/DFS、服务认证规范、时间服务、命名与目录服务、UUID等

       调用本地方法 和 调用远程方法之间的复杂度不可同日而语；RPC不可能再使用以内联为代表的传统编译优化来提升速度，“远程”意味着网络环境下的新问题，比如服务发现、负载均衡、熔断、隔离、降级、序列化协议、传输协议、认证、授权、网络安全、分布式数据一致性；因此，性能上，RPC和LPC的性能差距势必有鸿沟；分布式相较于单机本地调用，必然导致性能上的妥协，所以DEC未能在生产环境被实际应用。

       也就是说，一个功能在本地运行的时间足够长，长到分布式的调用开销与之相比完全可以忽略，才考虑进行分布式；换句话说，某个功能能够进行分布式，并不意味着，它就应该进行分布式。

1.2单体系统时代

       单体系统 aka 巨石系统，本质上，是一个进程上面运行着系统所有的代码，单体不意味着一定糟糕，糟糕的是大型的单体系统；对于小型系统，单台机器足够支撑其运行，开发、测试、部署都更简单，且系统中各模块间调用方式都是进程内调用，不会发生IPC，所以运行的效率也是极高的。

       单体的不足，必须在软件的性能需求超过单机、RD规模超过2 Pizza Team的前提下，才有讨论价值。

       另外，单体系统本身不太可能是“铁板一块”，纵向看，软件一般都是分层设计的，横向看，一般也能按照技术、功能、职责等维度，将软件拆分为多模块，或者从横向拓展来看，在负载均衡后部署若干相同单体系统副本，来分摊流量压力，也是常见的手段；因此，单体系统难点不在于拆分，而在于拆分后的自治与隔离能力。构建可靠系统的观念从追求尽量不出错，到正视出错是必然，才是微服务架构得以挑战并逐步取代单体架构的根本原因

       单体系统的利弊：

       优点：

       无需考虑网络分区、对象复制带来的性能损失，进程内调用简单高效

       缺点

       任一部分代码缺陷会带来全局影响，而不仅是影响某一个功能、模块；

       无法做到单独对一部分代码进行停止、更新、升级；也即是可维护性差，持续升级、更新时往往要指定专门的停机更新计划，灰度发布、A/B测试也更难；大规模的单体应用，在修改后的部署成本、技术升级后的迁移成本会变得很昂贵；另外单体常常意味着技术同构，单体的技术异构方案很难做到优雅