凤凰架构，凤凰表示能够涅槃重生。在软件工程里，系统难免出现问题，允许问题的出现，如何打造出能够"涅槃重生"的系统，使用怎样的架构是需要思考的问题。

计算机诞生初期受限于硬件算力，无法在单台服务器上完成一套软件系统的运行，因此就需要寻找多台计算机共同协作。不过从结果来看，分布式的问题不能一蹴而就解决， 不过历史上的伟大尝试用XX的话来阐述再适合不过：这次尝试最大的收获就是对 RPC、DFS 等概念的开创，以及得到了一个价值千金的教训： 某个功能能够进行分布式，并不意味着它就应该进行分布式，强行追求透明的分布式操作，只会自寻苦果

• 单体只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已

随着计算机算力的提高（摩尔定律），在单台服务器上运行一套完整的系统成为可能，而且单体系统在进程内的调用使得它简单、高效，不过这也带来了自治能力的欠缺和隔离性差。 譬如部分代码出现进程空间的过度消耗，会影响整个系统的业务；譬如代码在一个进程内，不能隔离，也就没有办法实现单独停止部分代码、单独升级一部分代码。 更重要的是，单体系统难以兼容"Phoenix"的特性，因为它潜在的表达: 单体系统的每一处代码和每一个模块都尽可能没有缺陷，这与"出错是必然"的观念相悖， 随着单体系统不断地庞大起来，完成项目的交付的困难也随之增加，所以单体架构不得不改变和演进。

• SOA 架构(Service Oriented Architecture): 面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式

它提出了像烟囱式架构、微内核架构和事件驱动架构等架构模式来对单体系统进行拆分，使拆分出的每一个子系统都能独立地部署、运行和更新。SOA本身是比较抽象的概念， 它不仅仅关注技术，而且还关注研发工程中的需求、管理和组织等问题，终极目标是希望总结出一套自上而下的软件研发方法论， 但是后来因为其过于严格的规范产生的复杂性使得它脱离群众，最终被淹没在了技术的海洋里。

• 微服务架构: 微服务是通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言， 不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

微服务更加追求自由实践，几乎摒弃了SOA里所有可以摒弃的约束和规范。可是没有了约束，"跟踪治理""负载均衡""熔断隔离""分布式事务"等问题便没有了统一的解决方案， 涌现出了很多技术、框架来解决以上问题，出现了百家争鸣的盛况。微服务架构就像一把双刃剑一样，一刃劈向SOA复杂的技术标准，但是另一刃的泠泠寒光也映向自己。

RPC面向过程调用（以算法和处理过程为中心，输入数据，输出结果），用来解决线程间的通信问题，起初为了让计算机能够像调用本地方法一样来调用远程方法，这使得程序员认为通信是没有成本的假象， 因此产生的滥用造成了分布式系统性能的降低。这也使得RPC调用在网络中的开销得到关注，并且认定它不能与IPC划等号，RPC应该是一种高层次的或者说语言层次的特征。

各个不同的RPC协议都需要解决以下三个问题来实现

• 入参和出参的序列化和反序列化
• 数据在两个服务器间的交换
• 方法的确定: 尤其是在不同语言间如何表示同一个方法

随着RPC框架的迭代更新，很难有某一种框架做到"尽善尽美"，功能多了，协议就要变得复杂，效率也会因此受影响；简单易用就必须遵循约定； 重视效率就需要采用二进制的序列化器和较底层的传输协议，支持的语言就会受限... 所以这就导致不断有新的RPC轮子出现，选择部分收益的同时就要付出另一部分的代价。

REST面向资源编程，它只能说是风格并不是远程服务调用协议，也没有任何规范文档的要求。REST虽然能够在移动端或者分布式服务间的通讯应用， 但是往往这需要以网络没有成为性能瓶颈为使用前提，在需要追求传输效率的场景里，REST 提升传输效率的潜力有限。

REST是"表征状态转移"的缩写，表征是我们想要请求的的资源的表现形式，比如我们请求的资源是某篇文章，那么HTML格式或PDF格式都是这个资源的不同表征； 而状态又分为无状态和有状态，都只是相对于服务器而言：有状态是服务器记住了我们当前在读的那一页，当我们想读下一页时，根据它的记录状态来返回下一页； 无状态则是需要客户端告诉服务端当前是哪一页，现在要它的下一页；转移则是服务器通过某种方式将当前页文章变成下一页文章，这就是表征状态转移。

服务器使用统一接口让表征状态发生转移：通过点击URI（统一资源标识符），对它们采取HTTP的GET、HEAD、POST等操作之后就会触发相应的表征状态转移。 而超文本驱动则可以这样理解，当我们阅读文章并不断地翻页时，翻页用到的内部链接是超文本提供的，而不是浏览器。 自描述信息指的是客户端需要以何种类型处理该信息，常用的方式是在HTTP Header中标识出Content-Type。

RESTful系统设计的核心原则是无状态和统一接口，无状态指的是在每一次客户端发送的请求中，应包含所有的必要上下文和会话信息， 服务端根据客户端传递的状态来执行业务处理逻辑；统一接口则是强调软件开发重点放在面向资源而不是面向服务上，比如登录和登出通过如果用面向服务来考虑的话， 是login()和logout()服务，如果采用面向资源的角度去考虑，可以将Session看成一种资源，登录对应Put Session，而登出则是Delete Session， 之后再想设计获取登录信息的需求那么则是Get Session，这样抽象程度更高，而且Fielding 建议系统应能做到每次请求中都包含资源的 ID， 所有操作均通过资源 ID 来进行；建议每个资源都应该是自描述的消息；建议通过超文本来驱动应用状态的转移。 除此之外还包含其他的原则：服务端与客户端分离、可缓存、分层系统和按需代码。

REST系统的好处是学习成本较低，更符合网络世界的交互方式。因为它的资源操作都映射到了HTTP的方法上，对所有的资源操作都是一致的；除此之外它绑定在HTTP协议之上， 无需再去考虑RPC中Wire Protocol的问题，但是与此相对的是，HTTP不支持的特性，REST也会因此束手无策。

• 面向资源的编程**只适合做 CRUD，面向过程、面向对象编程才能处理真正复杂的业务逻辑：比如网店下单功能，需要买东西、下单、冻结库存等其他很多步骤， 涉及到一系列资源的变化，如果采用面向资源的**，需要抽象出一种"事务"资源或者"结算单"资源，每次操作都需要待着事务或者结算单的ID， 而其他两种**则更擅长处理这种复杂的业务逻辑。但是并不是说面向资源编程不好，而是它们的立场不同而已。

  • 面向资源：将数据（资源）作为抽象的主体，把行为看作是统一的接口，为了符合网络世界的主流的交互方式
  • 面向过程：以算法和处理过程为中心，输入数据，输出结果，为了符合计算机世界中主流的交互方式
  • 面向对象：将数据和行为统一起来、封装成对象，为了符合现实世界的主流的交互方式

• REST 与 HTTP 完全绑定，不适合应用于要求高性能传输的场景中

• REST 没有传输可靠性支持