status
type
date
slug
summary
tags
category
icon
password
SOA 架构(Service-Oriented Architecture) 面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。
烟囱式架构
信息烟囱又名信息孤岛(Information Island),使用这种架构的系统也被称为孤岛式信息系统或者烟囱式信息系统。
特点:
- 不同的烟囱分组,数据是完全独立的,例如 BDE 和 CFG 两组烟囱系统是独立的
- 内部组件之间高度耦合
- 常见的架构用,如果公司有很多系统,但是每个系统又自己维护自己用户、组织、权限、OSS 等公共服务,那么这些系统我们一般都可以认为是信息孤岛。
- 这种架构对于希望使用数据挖掘来有效利用其数据的企业来说是一个障碍
微内核架构
微内核架构也被称为插件式架构(Plug-in Architecture)。

特点:
- 公共服务作为核心(Core System),例如上面的人员、组织、权限等
- 具体的业务系统以插件模块(Plug-in Modules)的形式存在
事件驱动架构

特点:
- 基于消息队列驱动
- 系统之间的通讯,通过消息进行通讯
- 各个子系统从管道里获取自己感兴趣、能够处理的事件消息,也可以为事件新增或者修改其中的附加信息,甚至可以自己发布一些新的事件到管道队列中去
- 系统之间,高度解耦
微服务架构
微服务是一种通过多个小型服务组合来构建单个应用的架构风格,这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言,不同的数据存储技术,运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
在英文版的维基百科上,仍然将微服务定义为一种 SOA 的变种形式,所以微服务在最初阶段与 SOA、Web Service 这些概念有所牵扯也完全可以理解,但现在来看,维基百科对微服务的定义已经颇有些过时了。
特点:
- 专注单一职责
- 语言无关
- 细颗粒度web服务
- 数据去中心化。数据是分散存储的,不同功能的模块数据,存储在不同库中
- 基础设施自动化。例如 CI/CD,docker、k8s 引入使用
优点:
- 自由度更高。多种微服务技术选择,通讯协议选择
- 微服务时代中,软件研发本身的复杂度应该说是有所降低。一个简单服务,并不见得就会同时面临分布式中所有的问题,也就没有必要背上 SOA 那百宝袋般沉重的技术包袱。需要解决什么问题,就引入什么工具;团队熟悉什么技术,就使用什么框架。
缺点:
分布式服务的问题,分布式事务,服务发现等