随着服务的壮大, 使用人数的增多, 业务的递增, 服务的扩展性尤为关键, 在不影响现有架构的情况下如何增加机器, 扩展功能?
基本思想和模式
一个字: 拆 . 把大的系统拆为小的系统, 下面是拆分的几个不同方法, 也是拆分依赖的不同维度, 以学生信息管理系统为例:
面向流程拆分. 将整个业务流程拆分为几个阶段, 比如展示层, 业务层, 数据层, 存储层
面向服务拆分. 将系统提供的服务拆分, 比如注册登录服务, 信息管理服务
面向功能拆分. 将系统提供的功能拆分, 比如将注册登录服务拆得更细致, 从而有手机号注册登录, 邮箱注册登录
那么我们作为架构师, 应该如何选择呢? 就是需要明白不同拆分方式的优缺点, 适用的场景:
面向流程拆分. 扩展时大部分情况只需要修改某一层的时候. 比如将存储层从 MySQL 扩展为同时支持 Oracle, 就只需要扩展存储层和数据层即可
面向服务拆分. 扩展时大部分情况只需要对某个服务扩展, 或增加新的服务时. 比如要增加身份证注册功能, 只需要修改注册服务
面向功能拆分. 扩展时大部分情况只需要对某个功能扩展, 或增加新的功能时. 比如要增加身份证注册功能, 无需修改任何服务, 只需要增加一个新的功能模块即可
面向流程拆分: 分层
很常见的架构模式, 也叫 N 层架构, N 至少是 2, 比如:
1)C/S,B/S 架构
划分的对象时整个业务系统, 将和用户交互的部分独立为一层, 后台作为另外一层, 如图:
2)MVC 架构
划分的对象是单个业务系统, 将不同的职责划分开
3) 逻辑分层架构
划分的对象可以是单个业务子系统, 也可以是整个业务系统, 将不同的职责划分开, 与 MVC 架构不同在于逻辑分层架构中的层是自顶向下依赖的. 比如操作系统内核架构, TCP/IP 架构, 比如安卓操作系统:
分层架构的核心在于: 保证各层之间的职责差异足够清晰 . 之所以能够支撑系统扩展, 本质在于隔离关注点, 就是每层中的组件只处理本层的逻辑. 这样就可以支持系统在某层上的快速扩展
但是除开分层, 还需要保证层与层之间的依赖是稳定的, 才能真正支撑快速扩展, 这个依赖就是接口
Linux 内核为支撑不同的文件系统格式, 抽象出来 VFS 文件系统接口, 如上. 如果没有 VFS, 那么即使增加一个文件系统, 也无法将依赖文件系统的系统应用上新的文件系统, 因为并不知道接口是什么, 而 VFS 统一了
优势: 各层之间自顶而下结构清晰, 强制约束层之间的关系是两两依赖, 依赖的数量固定
缺点: 如果层级多, 强制两两依赖将导致性能, 实现上的浪费, 架构也会混乱
场景: 适用互联网架构整体分层, 操作系统分层, 不适合互联网架构后台服务
面向服务拆分: SOA, 微服务
SOA
Service Oriented Architecture, 面向服务的架构, 是上世纪 90 年代就已经出现的架构模式:
服务. 所有业务都是一项服务, 服务就要对外提供开发的能力, 其他系统可以直接使用
ESB,Enterprise Service Bus, 企业服务总线, 类似于计算机总线, ESB 将企业中各个不同的服务连接在一起, 并对外提供各式各样需要的接口. 功能强大, 但需要完成非常多的协议和数据格式的相互转换, 工作量巨大, 且耗费大量计算性能, 容易成为系统的性能瓶颈
微服务
微服务这几年很火, 但也在早就出来了, 只不过 Martin Fowler 将它发扬光大
与 SOA 的区别:
服务粒度. 微服务更细, SOA 对应的是 "员工管理系统", 微服务是 "员工管理系统 - 员工信息管理" 服务
服务通信. 微服务仅仅使用统一的消息格式如 RESTFul,RPC 就好了, 而 SOA 的 ESB 将服务定义, 路由, 消息转换, 传递都给实现了, 是重量级的
服务交付. 微服务的交付理念是 "持续交付", 需要使用自动化测试, 持续集成, 自动化部署的敏捷最佳时间, 而 SOA 没有要求
应用场景. 微服务适合快速, 轻量级的 web 互联网系统, 而 SOA 适合庞大, 复杂, 异构的企业级系统
但微服务的坑是相当的多, 稍有不慎就会陷入焦油坑, 最后发现某些情况下几个单体应用的架构甚至甩了微服务好几条街
比如: 服务划分过细导致服务关系复杂, 团队开发效率下降, 调用链太长性能下降, 定位问题困难, 对运维自动化要求极高, 微服务数量递增管理难度极大... 从而步了 SOA 的后尘
更多微服务资料可参看:
面向功能拆分: 微内核
包含两类组件:
核心系统. 负责系统的功能组件如模块加载, 模块间通信
插件模块. 实现具体的业务逻辑比如手机号注册功能
比如在规则引擎架构上有以下体现, 比如电商促销中会有很多规则, 不可能把规则都写到代码里, 那样完全无法有效扩展, 架构如下:
设计关键点在于:
插件管理. 数据库
插件连接. 自己开发的规则引擎维护连接方式
插件通信. 数据流或事件流, 规则之间不需要相互依赖, 只要向规则引擎输出内容
参考
号外号外
最近在总结一些针对 Java 面试相关的知识点, 感兴趣的朋友可以一起维护~
地址: https://github.com/xbox1994/2018-Java-Interview
来源: http://www.tuicool.com/articles/nmQFNjy