从0开始学架构-可扩展架构模式

目录

可扩展概述

常见的拆分思路

分层架构

SOA架构

微服务

微内核架构

---

可扩展概述

软件系统，和硬件，建筑不同，天生和内在就具有可扩展性，即是其魅力也是其难点
魅力在于，可以通过修改和扩展，不断让软件系统具备更多的功能和特征，满足新需求顺应技术发展趋势
难点在于，如何以最小代价去扩展系统
所有的可扩展架构设计，最后的基本思想都是 拆！

常见的拆分思路

• 面向流程拆分，将整个业务流程拆分为几个阶段，每个阶段作为一部分
• 面向服务拆分，将系统提供的服务拆分，每个服务作为一部分
• 面向功能拆分，将系统提供的功能拆分，每个功能作为一部分

以学生管理系统为例
面向流程拆分
展示层，负责用户页面设计
业务层，负责具体业务逻辑处理，登陆/注册/信息管理
数据层，负责完成数据访问
存储层，负责数据的存储

面向服务拆分
注册，登陆，信息管理，安全设置等服务

面向功能拆分
每个服务都可以拆分为更多细粒度的功能
注册服务，提供多种方式进行注册，手机号/身份证/学生邮箱注册
登陆包括，手机/身份证/邮箱登陆
信息管理服务，包括基本信息管理，课程管理
安全设置，包括密码修改，找回密码等

可扩展方式
面向流程拆分
  扩展时大部分情况只需要修改某一层，少部分需要修改关联的两层
面向服务拆分
  对某个服务扩展时，只要扩展相关服务即可
面向功能拆分
  对某个功能扩展时，只需扩展相关功能即可

不同的拆分方式，得到不同的系统架构，经典的可扩展系统架构如下

• 面向流程拆分：分层架构
• 面向服务拆分：SOA，微服务
• 面向功能拆分：微内核架构

以管理系统为例

1. 整体系统采用面向服务拆分中的 微服务脚骨，拆分为注册服务，登陆服务，信息管理服务等独立子系统
2. 其中注册服务子系统本身又是采用面向流程拆分的分层架构
3. 登陆服务子系统采用的是面向功能拆分的微内核架构
    

 

分层架构

分层至少是2层以上
如C/S架构，B/S架构
常见的是3层架构，MVC，MVP
4-5层的架构比较少见，一般是比较复杂的系统才会超过5层，如操作系统内核这样的

逻辑架构分层，划分的对象可以是单个业务子系统，也可以是整个业务系统，划分的维度是指责
逻辑分层架构中的层是自顶向下依赖的，典型的有 操作系统内核架构，TCP/IP脚骨

分层架构详解

• 分层架构设计最核心的一点是，需要保证各个层之间的差异足够清晰
• 分之在于，隔离关注点，即每个层中的组件指挥处理本层的逻辑
• 分层结构这种约束，好处在于强制分层依赖限定为两两依赖，降低了整体系统的复杂度
• 缺点是每一次业务请求都要穿越所有的架构分层，性能有损失

 

 

SOA架构

SOA架构全程 面向服务的架构 Service Oriented Architechure
SOA更多在传统企业 制造业，金融业落地推广，在互联网行业并没有打的规模实践和推广
互联网行业推行SOA最早是亚马逊

SOA提出的背景是企业内部IT系统重复建设效率低下

1. 各企业部门有独立的IT系统，很多功能重复
2. 不同部门系统是不同语言编写的，需要多个IT系统整合
3. 各独立IT系统可能采购于不同供应商，实现技术不同

SOA提出三个概念
1.服务
    所有业务功能都是一项服务
2.ESB
    企业服务总线，将企业中各个不同的服务连在一起
    因为各个部门的服务是异构的，需要有统一标准，SOA是用ESB来屏蔽系统对外的不同接口
3.松耦合
    减少各个服务间的依赖和互相影响
    使用SOA后各个服务是相互独立运行的，甚至不清楚某个服务到底有多少对其他服务的依赖
经典的SOA架构如下

SOA的缺点就是ESB，其需要实现与各个系统间的协议转换，数据转换，透明的动态路由等功能
下图中ESB将JSON转换为Java

下图中ESB将REST协议转换RMI和AMQP两个不同的协议

ESB虽然功能强大，但实现中的协议有很多种，如JMS，WS，HTTP，RPC等
数据格式也有很多种，如XML，JSON，二进制，HTML等
要完成这么多协议和数据格式的相互转换，工作量和复杂度都很大，而且耗费大量计算性能，当ESB承载的消息太多时，ESB本身会成为整个系统的性能瓶颈
SOA的ESB也是无奈之举，SOA提出时，企业各种异构的IT系统已经存在很多年，完整重新或者按照统一标准改造成本非常大，只能通过ESB方式去适配已经存在的各种异构系统
如果是重新构建整个企业的IT系统，完全可以从一开始就制定好各种规范，那么SOA的ESB就无须存在了

 

 

微服务

2005年提出概念，2014年Mattin Flower写了关于微服务的论文

微服务与SOA的关系

1. 微服务是SOA的实现方式
2. 微服务是去掉ESB后的SOA
3. 微服务是一种和SOA相似但本质上不同的架构理念

具体的不同

1. 服务粒度，微服务更细
2. 服务通讯，SOA的ESB通讯管道很强，微服务的通讯仅传输数据
3. 服务交付，微服务要求快速交付
4. 应用场景，SOA更适合庞大复杂异构的企业系统，微服务适合轻量级互联网系统

微服务和SOA是适用不同场景的，并非谁好谁差

微服务的陷阱

1. 服务划分过细，服务间关系复杂
2. 服务数量田铎，团队效率急剧下降
3. 调用链太长性能下降
4. 调用链太长问题定位困难
5. 没有自动化支撑无法快速交付
6. 没有服务治理，微服务数量多了后管理混乱

微服务最佳实践

• 微服务的坑总结如下
• 微服务拆分过细，过分强调small
• 微服务基础设施不健全，忽略了automated
• 微服务并不轻量级，规模大了后，lightweight不再适用

1.服务粒度
  三个火枪手的微服务拆分粒度原则
  一个微服务三个人负责开发
  稳定和维护阶段可以一人负责一个或几个微服务
2.拆分方法
  基于业务逻辑拆分
  基于可扩展拆分
  基于可靠性拆分
  基于性能拆分

基础设施
大部分人关注的是微服务的small，lightweight特征，但实际上真正决定微服务成败的，是automated
当微服务库划分不合理，拆分后自动化和相关的基础设施不健全，补起来短则1年多则2-3年
因为基础设施太多了

基础设施总结

1. 自动化测试
2. 自动化部署
3. 配置中心
4. 接口框架，定义标准的JSON格式
5. API网关，统一一批微服务对外网提供接口
6. 服务发现，自理式，代理式
7. 服务路由
8. 服务容错，请求重试，流控，服务隔离
9. 服务监控
10. 服务跟踪，采样跟踪，染色跟踪
11. 服务安全，接入安全，数据安全，传输安全
     

微内核架构

包含两类组件，核心系统，插件模块

• 核心系统负责和具体业务功能无关的通用功能，如模块加载，模块通讯
• 插件模块负责实现具体的业务逻辑

设计关键点

• 1.插件管理
• 2.插件连接
• 3.插件通讯

OSGi架构
一个国际标准组织，最初用于广域网和局域网设备上展开业务的基础平台，用于嵌入式是被
后被用于PC领域，Eclipse使用OSGi标准开发了微内核架构
类似的还有Apache Felix，Srping DM
模块层
生命周期层
服务层

规则引擎架构
规则引擎作为微内核，执行引擎解析配置好的业务流
商品促销打折优惠，用代码实现改动很麻烦，用规则引擎就可以很灵活应对
可扩展
易理解
高效率
其插件之间不需要通讯，一个插件输出，一个插件将其输入即可
常见的规则引擎工具是JBoss Drools，基于Rete算法