技术角 | 架构学习书摘总结（四）可扩展架构模式（上）

2020-05-13 09:41:38 浏览数 (1)

最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。

本文是该书第四部分上半部分，是书中第十一至十三章，主要介绍可扩展模式、分层架构、SOA架构等，涉及到可扩展思想、分层、SOA等内容。

目录

▪第十一章 可扩展模式

▪第十二章 分层架构

▪第十三章 SOA架构

第十一章 可扩展模式

  1. 软件系统的这种天生和内在的可扩展的特性，难点体现在如何以最小的代价去扩展系统，如何避免扩展时改动范围太大，是软件架构可扩展性设计的主要思考点。
  2. 所有的可扩展性架构设计，背后的基本思想都可以总结为一个字：拆！所谓拆，就是将原本大一统的系统拆分成多个规模小的部分，扩展时只修改其中一部分即可，无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风险。这里的拆是让软件系统变得具备更好的可扩展性。形象的说，软件系统中的“拆”是建设性的，因此难度要高得多。
  3. 常见拆分思路： 从范围上来说，流程→服务→功能。
    • 优点：对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无需修改所有的服务。
    • 优点：对某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可，无需修改所有的服务。
    • 优点：扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改。
    1. 面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。
    2. 面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。
    3. 面向功能拆分：将系统提供的功能拆分，每个功能作为一部分。
  4. 不同的拆分方式，本质上决定了系统的扩展方式。而合理的拆分，能够强制保证即使程序员出错，出错的范围也不会太广，影响也不会太大。
  5. 典型的可扩展系统架构； 上述可扩展系统架构并不是非此即彼的，而是可以在系统架构设计中进行组合使用的。
    1. 面向流程拆分：分层架构。
    2. 面向服务拆分：SOA、微服务。
    3. 面向功能拆分：微内核架构。

第十二章 分层架构

  1. 分层架构是很常见的架构模式，通常情况下，N至少为2层。例如，C/S架构、B/S架构。常见的是3层架构（例MVC、MVP架构）、4层架构、5层架构比较少见，一般是比较复杂的系统才会达到或超过5层，例操作系统内核架构。几种分层架构：
    1. C/S、B/S架构：划分对象是整个业务系统，划分的维度是用户交互。
    2. MVC架构、MVP架构：划分的对象是单个业务子系统，划分的维度是职责，将不同的职责划分到独立层，但各层的依赖关系比较灵活。
    3. 逻辑分层架构：划分的对象可以是单个业务子系统，也可以是整个业务系统，划分的维度也是职责。虽然都是基于职责划分，但逻辑分层架构和MVC架构、MVP架构的不同点在于，逻辑分层架构中的层是自顶向下依赖的。典型的有操作系统内核架构、TCP/IP架构。
  2. 分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构。
  3. 分层架构之所以能够较好地支撑系统扩展，本质在于：隔离关注点(separation of concerns)，即每个层中的组建只会处理本层的逻辑。
  4. 并不是简单地分层就一定能够实现隔离关注定从而支撑快速扩展，分层时要保证层与层之间的依赖是稳定的，才能真正支撑快速扩展。
  5. 对于操作系统这类复杂的系统，接口本身也可以成为独立的一层。而对于一个简单的业务系统，接口可能就是Java语言上的几个interface定义，这种情况下如果独立为一层，看起来就比较重了。
  6. 分层结构的另外一个特点就是层层传递，也就是说一旦分层确定，整个业务流程是按照层进行依次传递的，不能在层之间进行跳跃。分层结构的这种约束，好处在于强制将分层依赖限定为两两依赖，降低了整体系统复杂度。但分层结构的代价就是冗余，也就是说，不管这个业务有多么简单，每层都必须要参与处理，甚至可能每层都写了一个简单的包装函数。
  7. 不建议自由选择绕过分层约束，分层架构的优势就体现在通过分层强制约束两两依赖，一旦自由选择绕过分层，时间一长，架构就会变得混乱。这样做就失去了分层架构的意义，也导致后续扩展时无法控制受影响范围，牵一发而动全身，无法支持快速扩展。除此以外，虽然分层架构的实现在某些场景下看起来有些繁琐和冗余，但复杂度却很低。
  8. 分层架构除了冗余另一个典型缺点就是性能，因为每一次业务请求都需要穿越所有的架构分层，有一些事情是多余的，多少都会有一些性能的浪费。但到了现在，硬件和网络的性能有了质的飞跃，其实分层模式理论上的这点性能损失，在实际应用中，绝大部分场景下都可以忽略不计。

第十三章 SOA架构

  1. SOA全称是Service Oriented Architecture，中文翻译为“面向服务的架构”，诞生于20世纪90年代。SOA提出的背景是企业内部IT系统重复建设且效率低下。
  2. SOA三个关键概念：
    1. 服务：所有业务功能都是一项服务，服务就意味着要对外提供开放的能力，当其他系统需要使用这项功能时，无需定制化开发。
    2. ESB：ESB的全称是Enterprise Service Bus，中文翻译为“企业服务总线”。从名字就可以看出，ESB参考了计算机总线的概念。
    3. 松耦合：松耦合的目的是减少各个服务之间的依赖和互相影响。
  3. SOA架构是比较高层级的架构设计概念，一般情况下我们可以说某个企业采用了SOA的架构来构建IT系统，但不会说某个独立系统采用了SOA架构。
  4. SOA解决了传统IT系统重复建设和扩展效率低的问题，但其本身也引入了更多的复杂性。SOA最为人诟病就是ESB，ESB需要实现与各种系统间的协议转换、数据转换、透明的动态路由等功能，工作量和复杂度都很大，而且转换需要耗费大量计算性能。ESB本身会成为整个系统的性能瓶颈。
系统架构 架构设计 mvc

0 人点赞