凤凰架构读书笔记1-服务架构史，常用的远程服务访问框架

服务的架构史

分布式需要解决的问题和难点：

• 远程服务在哪里：服务发现
• 有多少个：负载均衡
• 网络出现分区，超时和服务出错了怎么办：熔断，隔离和降级
• 方法的参数与返回结构如何表示：序列化协议
• 信息如何传输：传输协议
• 服务权限如何管理：认证和授权
• 如何保证通信的安全性：网络安全层
• 如何令调用不同机器的服务返回相同的结果：分布式的一致性

单机系统

首先单机系统不能简单理解为不可拆分的。

• 纵向角度来看，可以对系统进行分层（MVC，DDD） 等分层架构。
• 横向角度，可以通过 JAR、WAR、DLL、Assembly 或者其他模块格式来构成。即使是以横向扩展（Scale Horizontally）的角度来衡量，在负载均衡器之后同时部署若干个相同的单体系统副本，以达到分摊流量压力的效果，也是非常常见的需求。

真正的问题：

• 隔离性低：由于所有代码都运行在同一个进程空间之内，所有模块、方法的调用都无须考虑网络分区、对象复制这些麻烦的事和性能损失。获得了进程内调用的简单、高效等好处的同时，也意味着如果任何一部分代码出现了缺陷 ，过度消耗了进程空间内的资源，所造成的影响也是全局性的、难以隔离的。
• 可维护性低：由于所有代码都共享着同一个进程空间，不能隔离，也就无法做到单独停止、更新、升级某一部分代码。
• 存在程序异构问题：必须要求所有的模块使用相同的语言。

SOA 时代（Servervice Oriented Architecture，面向服务的架构）

对大型的单体系统进行拆分，让每一个子系统都能独立地部署、运行、更新。常见的三种架构方案：

烟囱式架构

• 信息烟囱又叫信息孤岛。使用这种架构的系统也被称为孤岛式信息系统或者烟囱式信息系统。它指的是一种完全不与其他相关信息系统进行互操作或者协调工作的设计模式。这样完全不进行交互的模式不符合真实业务情况。

内核架构

• 微内核架构也被称为插件式架构。实际场景中不可能做到烟囱式那种完全无交互，那么可以尝试将这些交互交给一个公共的核心来做。这就是 微内核架构。
  

• 具体的业务系统以插件模块（Plug-in Modules）的形式存在，微内核将主数据，连同其他可能被各子系统使用到的公共服务、数据、资源集中到一块，成为一个被所有业务系统共同依赖的核心。

• 缺点：