读书笔记--凤凰架构--其二

单体系统时代
单体架构中“单体”只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信。

单体架构的系统又叫巨石系统。单体架构本身具有简单的特性，简单到在相当长的时间内，大家都已经习惯了软件架构就应该是单体这种样子，所以并没有多少人将“单体”视作一种架构来看待。

和很多书中的内容不同的是，单体其实并不是一个“反派角色”，单体并没有大家口中的那么不堪。实际上，它时运行效率最高的一种架构风格。基于软件的性能需求超过了单机，软件开发人员规模扩大这样的情况，才体现了单体系统的不足之处。

单体架构由于所有代码都运行在同一个进程空间之内，所有模块、方法的调用都无须考虑网络分区、对象复制这些麻烦的事和性能损失。一方面获得了进程内调用的简单、高效等好处的同时，另一方面也意味着如果任何一部分代码出现了缺陷，过度消耗了进程空间内的资源，所造成的影响也是全局性的、难以隔离的。比如内存泄漏、线程爆炸、阻塞、死循环等问题，都会影响整个程序，而不仅仅是影响某一个功能、模块本身的正常运作。

同样的，由于所有代码都共享着同一个进程空间，不能隔离，也就无法做到单独停止、更新、升级某一部分代码，所以从可维护性来说，单体系统也是不占优势的。程序升级、修改缺陷往往需要制定专门的停机更新计划，做灰度发布、A/B 测试也相对更复杂。

除了以上问题是单体架构的缺陷外，作者提出，最重要的还是：单体系统很难兼容“Phoenix”的特性

单体架构这种风格潜在的观念是希望系统的每一个部件，每一处代码都尽量可靠，靠不出或少出缺陷来构建可靠系统。但是单体靠高质量来保证高可靠性的思路，在小规模软件上还能运作良好，但系统规模越大，交付一个可靠的单体系统就变得越来越具有挑战性。

为了允许程序出错，为了获得隔离、自治的能力，为了可以技术异构等目标，是继为了性能与算力之后，让程序再次选择分布式的理由。在单体架构后，有一段时间是在尝试将一个大的单体系统拆分为若干个更小的、不运行在同一个进程的独立服务，这些服务拆分方法后来导致了面向服务架构(Service-Oriented Architecture)的一段兴盛期，这就是SOA 时代。

SOA时代
SOA是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。

三种有代表性的SOA

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

这样的系统其实并没有什么“架构设计”可言。这样完全不进行交互的模式不符合真实业务情况。

微内核架构
微内核架构也被称为插件式架构。微内核将主数据，连同其他可能被各子系统使用到的公共服务、数据、资源集中到一块，成为一个被所有业务系统共同依赖的核心(Kernel，也称为 Core System)，具体的业务系统以插件模块(Plug-in Modules)的形式存在，这样也可提供可扩展的、灵活的、天然隔离的功能特性。

这种模式适合桌面应用程序和Web 应用程序。对于平台型应用来说，经常会加入新的功能，就很像时不时加一个新的插件模块进来所以微内核架构比较适合。微内核架构也可以嵌入到其他的架构模式之中，通过插件的方式来提供新功能的定制开发能。

微内核架构也有它的局限和使用前提，架构中这些插件可以访问内核中一些公共的资源，但不会直接交互。但是无论是企业信息系统还是互联网应用必须既能拆分出独立的系统，也能让拆分后的子系统之间顺畅地互相调用通信。