高校信息化系统架构演变-复旦大学
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 《Exploring the Duality Between Product and Organizational Architectures》书中给了一个很有 意思的观点，组织的耦合度与系统的模块化成正比
• 微服务架构本质上在强调松耦合的架构，因此在微服务 架构迁移前，我们有必要对组织进行微调，确保独立的、 小的团队交付一个微服务，同时小团队是微服务的 Owner（除了负责开发外，同时负责测试和运维）。 这会极大提供团队的责任感，加速微服务的自治和交付 能力。
对架构设计原则、运维 管理模式等提出要求
2.3
从哪里开始?
以实际例子讨论
• 全校业务系统都会使用到的用户信息 • 学号-姓名-性别等等
• 复旦来自LDAP，并不一定准确 • 都交给核心库？
以实际例子讨论
• 一卡通充值
• API 同时为微信入口和 web 提供充值入口服务
• 业务具有一致性
• 但并未彻底服务化，API 并不完善
以实际例子讨论
• 课程表、成绩服务
• 多么好的标准服务风格
• 为个人数据中心服务 • 为微信服务、APP、H5 • 是否可能开放给学生写自己的课程表？
微信、APP、服务门户（eHall）
• 互联网风格的服务入口 • 横截面型系统
• 数据横跨多个系统 • 业务横跨多个系统（部门）
复旦的尝试
• 复旦将从如下角度 开始尝试
优点
• 模块界限清晰，职责明确
• 微服务适合多业务相互配合 的场景
• 校园数据复杂
• 数据分离有利于数据治理工 作进行
提升信息化工作效率
挑战
• 架构变更难
• 过多的历史遗留系统 • 技术力量薄弱
• 通信增加
• 数据交换渠道、数据交换量
• 数据一致性问题
• 接口一致性问题
对数据分离模式、API 设 计模式等提出要求
• 从复旦实际环 境实验，推广 至兄弟高校
What's The Next Big Thing？
• Microservices • 微服务应该能解决很多问题 • 也带来很多挑战 • 技术并非关键，切实解决眼前实际的工作需求才是出发点
• 以上是复旦关于微服务的一些思考，我们已经开始进行研究工 作，也欢迎兄弟院校共同探讨。
• 但后面我其实会讲到它们还真能比较搭配
Microservices, 微服务
• 微服务(Microservices)是一种架构风格，一个 大型复杂软件应用由一个或多个微服务组成
• 系统中的各个微服务可被独立部署，各个微服务之间 是松耦合的
• 每个微服务仅关注、并很好地完成一件任务 • 在所有情况下，每个任务代表着一个小的业务能力
• 对变更管理提出高要求
• 多模块配合对运维提出高要求
• 跨组件的安全管控
大 量 通 信
数据一致性问题
1. 跨服务数据请求 2. 共享的代码型数据，静态数
据（服务化？代码化？复制 表？） 3. 数据约束关系（传统的外键 约束不可行） 4. 传统的一张表会被分裂成多 张（对数据重新设计的过程）
管理运维问题
• 从小型标准服务开始 • 转换为 API 方式，
稳定设计 • 引入日志、审计、权
限等 • 监控与报警
微服务
范围
用户信息服务
全校业务系统
日程服务
全校业务系统
地理信息服务
全校业务系统
统一消息服务
全校业务系统
课程信息服务
教务、个人数据中心、微 信、APP等
成绩信息服务
教务、个人数据中心、微 信、APP等
境
• 提供容器环境
• 正在进行容器平台的评估工作
2.2
高校如何引入微服务
高校如何引入微服务架构
• 需要梳理微服务架构方式
• 全局考虑全校业务系统和数据 • 支撑业务爆发、快速交付等能力 • 和软件供应商共同设计架构
• 增强运维能力
• 自动化测试、持续集成与自动化部署
微服务仍存在挑战 – 针对校园环境分析
• 从数据视图转换为 API • 从紧耦合系统中剥离数据构建服务
• 微服务相对独立
• 解除耦合 • 独立伸缩
痛点与方案 – 数据使用缺乏管理
• 缺乏审计和安全管控，使用 情况不明
• 跨业务数据调用无统一规范， 存在故障隐患
• 依赖核心库，存在性能影响
• 数据取自不同系统，结果不 一致（统计规则、代码、时 间节点）
• 主动服务、 高效协同
• 突出了模块 化结构、重 构业务系统
痛点与方案 - 人员/技术不足
• 精力分散于业务梳理工作
• 不得不依托独立软件开发商 （ISV）进行服务
• 单一厂商绑架
• 厂商之间协同难度较大
• 必须依赖于ISV进行交付后 的运维工作
• 微服务方式为松耦合架构
• 独立小型团队可以胜任 • 灵活选择技术路线
支付信息服务(查询) 支付平台、微信、APP、 涉及支付业务的系统
计划的实施路径
服务梳理
构建测试 服务
整理API 标准
构建运维 平台
梳理微服 务模式
计划的实施路径
• 采用逐步演化方式进行
服务梳理
API管理
• 从单向提供数 据，到双向处 理
• 从单一业务系 统，到跨业务 系统
• 从小范围，到 覆盖全校范围
• Chris Richardson的系列介绍文章
传统的架构
应用核心是业务逻辑，由定义 服务、域对象和事件的模块完 成。
围绕着核心的是与外界打交道 的适配器。
适配器包括数据库访问组件、 生产和处理消息的消息组件，
以及提供API或者UI访问支持 的web模块等。
SMS
界面
支付
EMail
微服务架构
每一个微服务都是微型六角 形应用，都有自己的业务逻 辑和适配器。
一些微服务还会发布API给 其它微服务和应用客户端使 用。
数据库的组织和依赖模式改变了
1.3
微服务的优劣
优劣分析
优点
• 模块界限清晰，职责明确
• 多团队协作变得可行
• 模块间依赖减少
• 开发语言 • 数据库 • 轻量环境即可支撑
• 适合云架构的伸缩部署
缺点
• 通信增加
• 数据交换渠道、交换量
• 数据一致性复杂
• 微服务拆分之后，最大的挑战来自于运维、监控、 故障处理，如果团队没有微服务运行的经验，故 障之后无法快速定位、快速回复，会受到更大的 业务压力，因此后期的微服务运营平台或者管理 平台对团队异常重要，需要配套设计及时跟上， 支撑微服务的运行管理。
1.4
关于微服务的观点
组织的耦合度与系统的模块化成正比
高校信息化系统架构演变
What's The Next Big Thing, Micro? 复旦大学 刘百祥
提纲
1.Micro? 2.微服务是否适合高校？
问题一
Micro?
1.1
Micro，微
Micro，微？
• 微服务和微信并不是一件事，此微非彼微
• Microservices • Wechat
• 从仅API 方式 提供数据，到 完整的API 版 本、日志记录、 调用分析
• 从简单授权， 到完整的安全 管控、多模式 授权
运维管理
• 先从仅关注服 务状态，随后 关注伸缩能力
• 最后引入自动 化测试、持续 集成与自动化 部署
建设模式
• 先从改变自主 开发系统架构， 和 ISV 共同探 讨外包系统架 构，再到全校 业务架构
面向用户服务的发展方向
信息门户
应用门户
服务门户
办事服 务大厅
一站式/智 慧校园
• 新闻抓取、 信息聚合
• 提供了单向 的信息聚合 与发布服务
• 应用集合、 单点登录
• 集成了个 人信息中 心、部门 数据展示
• 服务分类、 • 流程再造、
应用集成
服务碎片
• 初现了迎 新、离校 等跨部门 服务特征
• 展现了一站 式服务、平 台化支持的 雏形
• 微服务改变运维团队工作重 心
• 无需了解巨无霸系统
源自文库
痛点 - 系统迭代难度大
• 大量巨无霸、紧耦合（烟囱） 系统
• 模块耦合紧密，运维难度大 • 组件依赖严重，改造、测试难度大 • 技术陈旧，更新缓慢，开发周期长
（服务商能力有限、人员变更频繁）
方案 – 系统迭代难度大
• 逐步改善巨无霸系统
• 改变服务提供方式
Elastic
Micro
单块架构
基本无人使用
成本低，但二 次开发困难
垂直架构 有一定模块化
负载均衡
SOA架构
服务管控
RPC技术(Romote Procedure Call)
微服务架构 高密度部署 原子、自治
不同的架构风格
• Monolithic VS Microservices • 单体式架构 VS 微服务架构
微服务 VS SOA
• 微服务的出现应当归功于SOA原则的成功 • 微服务不再强调使用 ESB，转而使用 API
Gateway • 更细粒度的通讯，Restful 方式 • 微服务使用各自为政，去中心式的架构模式
问题二
微服务是否适合高校？
2.1
高校信息化架构现状
我们的系统架构演变
• 初建：定制、开发平台 • 共享库：ETL支撑下的多业务系统 • 门户：应用集合，单点登录 • 服务门户（一站式服务）
技术的发展催生了微服务
• 部分 IT 企业开始转向 DevOps （Development + Operations） 模式
• 快速交付需求
开发
测试
• 降低多环境多配置的维护难度
• 构建轻量化 PaaS 平台
运维
技术的成熟催生了微服务架构
1.2
架构风格演变
系统架构模式演化
All in one
Vertical
谢谢
• 统一规划设计业务数 据的隔离模式
• 使用标准接口
• 数据独立提供服务
• 增加状态记录、使用 分析、安全控制、审 计等功能
服务模式与建设方式转型
• 用互联网方式服务用户
• 多终端、多场景 • 简化用户工作，重梳理业务流程
• 建设平台化系统
• 工作流、统一消息、统一报表
平台化 Platform
标准化 Standardization
模块化 Modularization
通用化 Universalization
复旦eHall 的模式已经在向轻量化演变
• 平台化支持
• 工作流、表单填写、数据交 换、应用门户
• 业务数据和逻辑数据在平 台间传递
• 经过简化的单个业务可以 脱离传统业务运行
环境基础
• 提供虚拟化环境
• 去小机已经基本完成 • 大量业务系统运行于虚拟化环
微服务仍存在挑战 – 针对校园环境分析
优点
• 团队更灵活
• 灵活选择轻型服务商 • 灵活选择技术架构
• 技术选型灵活
• 开发语言 • 数据库 • 轻量环境即可支撑
• 适合云架构的自动伸缩部署
改善用户体验
挑战
• 需要从校园整体出发，和 ISV 共同 设计业务架构
• 运维管理
• 高校的运维力量相对弱 • 新的技术手段应用有限
• 微服务架构本质上在强调松耦合的架构，因此在微服务 架构迁移前，我们有必要对组织进行微调，确保独立的、 小的团队交付一个微服务，同时小团队是微服务的 Owner（除了负责开发外，同时负责测试和运维）。 这会极大提供团队的责任感，加速微服务的自治和交付 能力。
对架构设计原则、运维 管理模式等提出要求
2.3
从哪里开始?
以实际例子讨论
• 全校业务系统都会使用到的用户信息 • 学号-姓名-性别等等
• 复旦来自LDAP，并不一定准确 • 都交给核心库？
以实际例子讨论
• 一卡通充值
• API 同时为微信入口和 web 提供充值入口服务
• 业务具有一致性
• 但并未彻底服务化，API 并不完善
以实际例子讨论
• 课程表、成绩服务
• 多么好的标准服务风格
• 为个人数据中心服务 • 为微信服务、APP、H5 • 是否可能开放给学生写自己的课程表？
微信、APP、服务门户（eHall）
• 互联网风格的服务入口 • 横截面型系统
• 数据横跨多个系统 • 业务横跨多个系统（部门）
复旦的尝试
• 复旦将从如下角度 开始尝试
优点
• 模块界限清晰，职责明确
• 微服务适合多业务相互配合 的场景
• 校园数据复杂
• 数据分离有利于数据治理工 作进行
提升信息化工作效率
挑战
• 架构变更难
• 过多的历史遗留系统 • 技术力量薄弱
• 通信增加
• 数据交换渠道、数据交换量
• 数据一致性问题
• 接口一致性问题
对数据分离模式、API 设 计模式等提出要求
• 从复旦实际环 境实验，推广 至兄弟高校
What's The Next Big Thing？
• Microservices • 微服务应该能解决很多问题 • 也带来很多挑战 • 技术并非关键，切实解决眼前实际的工作需求才是出发点
• 以上是复旦关于微服务的一些思考，我们已经开始进行研究工 作，也欢迎兄弟院校共同探讨。
• 但后面我其实会讲到它们还真能比较搭配
Microservices, 微服务
• 微服务(Microservices)是一种架构风格，一个 大型复杂软件应用由一个或多个微服务组成
• 系统中的各个微服务可被独立部署，各个微服务之间 是松耦合的
• 每个微服务仅关注、并很好地完成一件任务 • 在所有情况下，每个任务代表着一个小的业务能力
• 对变更管理提出高要求
• 多模块配合对运维提出高要求
• 跨组件的安全管控
大 量 通 信
数据一致性问题
1. 跨服务数据请求 2. 共享的代码型数据，静态数
据（服务化？代码化？复制 表？） 3. 数据约束关系（传统的外键 约束不可行） 4. 传统的一张表会被分裂成多 张（对数据重新设计的过程）
管理运维问题
• 从小型标准服务开始 • 转换为 API 方式，
稳定设计 • 引入日志、审计、权
限等 • 监控与报警
微服务
范围
用户信息服务
全校业务系统
日程服务
全校业务系统
地理信息服务
全校业务系统
统一消息服务
全校业务系统
课程信息服务
教务、个人数据中心、微 信、APP等
成绩信息服务
教务、个人数据中心、微 信、APP等
境
• 提供容器环境
• 正在进行容器平台的评估工作
2.2
高校如何引入微服务
高校如何引入微服务架构
• 需要梳理微服务架构方式
• 全局考虑全校业务系统和数据 • 支撑业务爆发、快速交付等能力 • 和软件供应商共同设计架构
• 增强运维能力
• 自动化测试、持续集成与自动化部署
微服务仍存在挑战 – 针对校园环境分析
• 从数据视图转换为 API • 从紧耦合系统中剥离数据构建服务
• 微服务相对独立
• 解除耦合 • 独立伸缩
痛点与方案 – 数据使用缺乏管理
• 缺乏审计和安全管控，使用 情况不明
• 跨业务数据调用无统一规范， 存在故障隐患
• 依赖核心库，存在性能影响
• 数据取自不同系统，结果不 一致（统计规则、代码、时 间节点）
• 主动服务、 高效协同
• 突出了模块 化结构、重 构业务系统
痛点与方案 - 人员/技术不足
• 精力分散于业务梳理工作
• 不得不依托独立软件开发商 （ISV）进行服务
• 单一厂商绑架
• 厂商之间协同难度较大
• 必须依赖于ISV进行交付后 的运维工作
• 微服务方式为松耦合架构
• 独立小型团队可以胜任 • 灵活选择技术路线
支付信息服务(查询) 支付平台、微信、APP、 涉及支付业务的系统
计划的实施路径
服务梳理
构建测试 服务
整理API 标准
构建运维 平台
梳理微服 务模式
计划的实施路径
• 采用逐步演化方式进行
服务梳理
API管理
• 从单向提供数 据，到双向处 理
• 从单一业务系 统，到跨业务 系统
• 从小范围，到 覆盖全校范围
• Chris Richardson的系列介绍文章
传统的架构
应用核心是业务逻辑，由定义 服务、域对象和事件的模块完 成。
围绕着核心的是与外界打交道 的适配器。
适配器包括数据库访问组件、 生产和处理消息的消息组件，
以及提供API或者UI访问支持 的web模块等。
SMS
界面
支付
微服务架构
每一个微服务都是微型六角 形应用，都有自己的业务逻 辑和适配器。
一些微服务还会发布API给 其它微服务和应用客户端使 用。
数据库的组织和依赖模式改变了
1.3
微服务的优劣
优劣分析
优点
• 模块界限清晰，职责明确
• 多团队协作变得可行
• 模块间依赖减少
• 开发语言 • 数据库 • 轻量环境即可支撑
• 适合云架构的伸缩部署
缺点
• 通信增加
• 数据交换渠道、交换量
• 数据一致性复杂
• 微服务拆分之后，最大的挑战来自于运维、监控、 故障处理，如果团队没有微服务运行的经验，故 障之后无法快速定位、快速回复，会受到更大的 业务压力，因此后期的微服务运营平台或者管理 平台对团队异常重要，需要配套设计及时跟上， 支撑微服务的运行管理。
1.4
关于微服务的观点
组织的耦合度与系统的模块化成正比
高校信息化系统架构演变
What's The Next Big Thing, Micro? 复旦大学 刘百祥
提纲
1.Micro? 2.微服务是否适合高校？
问题一
Micro?
1.1
Micro，微
Micro，微？
• 微服务和微信并不是一件事，此微非彼微
• Microservices • Wechat
• 从仅API 方式 提供数据，到 完整的API 版 本、日志记录、 调用分析
• 从简单授权， 到完整的安全 管控、多模式 授权
运维管理
• 先从仅关注服 务状态，随后 关注伸缩能力
• 最后引入自动 化测试、持续 集成与自动化 部署
建设模式
• 先从改变自主 开发系统架构， 和 ISV 共同探 讨外包系统架 构，再到全校 业务架构
面向用户服务的发展方向
信息门户
应用门户
服务门户
办事服 务大厅
一站式/智 慧校园
• 新闻抓取、 信息聚合
• 提供了单向 的信息聚合 与发布服务
• 应用集合、 单点登录
• 集成了个 人信息中 心、部门 数据展示
• 服务分类、 • 流程再造、
应用集成
服务碎片
• 初现了迎 新、离校 等跨部门 服务特征
• 展现了一站 式服务、平 台化支持的 雏形
• 微服务改变运维团队工作重 心
• 无需了解巨无霸系统
源自文库
痛点 - 系统迭代难度大
• 大量巨无霸、紧耦合（烟囱） 系统
• 模块耦合紧密，运维难度大 • 组件依赖严重，改造、测试难度大 • 技术陈旧，更新缓慢，开发周期长
（服务商能力有限、人员变更频繁）
方案 – 系统迭代难度大
• 逐步改善巨无霸系统
• 改变服务提供方式
Elastic
Micro
单块架构
基本无人使用
成本低，但二 次开发困难
垂直架构 有一定模块化
负载均衡
SOA架构
服务管控
RPC技术(Romote Procedure Call)
微服务架构 高密度部署 原子、自治
不同的架构风格
• Monolithic VS Microservices • 单体式架构 VS 微服务架构
微服务 VS SOA
• 微服务的出现应当归功于SOA原则的成功 • 微服务不再强调使用 ESB，转而使用 API
Gateway • 更细粒度的通讯，Restful 方式 • 微服务使用各自为政，去中心式的架构模式
问题二
微服务是否适合高校？
2.1
高校信息化架构现状
我们的系统架构演变
• 初建：定制、开发平台 • 共享库：ETL支撑下的多业务系统 • 门户：应用集合，单点登录 • 服务门户（一站式服务）
技术的发展催生了微服务
• 部分 IT 企业开始转向 DevOps （Development + Operations） 模式
• 快速交付需求
开发
测试
• 降低多环境多配置的维护难度
• 构建轻量化 PaaS 平台
运维
技术的成熟催生了微服务架构
1.2
架构风格演变
系统架构模式演化
All in one
Vertical
谢谢
• 统一规划设计业务数 据的隔离模式
• 使用标准接口
• 数据独立提供服务
• 增加状态记录、使用 分析、安全控制、审 计等功能
服务模式与建设方式转型
• 用互联网方式服务用户
• 多终端、多场景 • 简化用户工作，重梳理业务流程
• 建设平台化系统
• 工作流、统一消息、统一报表
平台化 Platform
标准化 Standardization
模块化 Modularization
通用化 Universalization
复旦eHall 的模式已经在向轻量化演变
• 平台化支持
• 工作流、表单填写、数据交 换、应用门户
• 业务数据和逻辑数据在平 台间传递
• 经过简化的单个业务可以 脱离传统业务运行
环境基础
• 提供虚拟化环境
• 去小机已经基本完成 • 大量业务系统运行于虚拟化环
微服务仍存在挑战 – 针对校园环境分析
优点
• 团队更灵活
• 灵活选择轻型服务商 • 灵活选择技术架构
• 技术选型灵活
• 开发语言 • 数据库 • 轻量环境即可支撑
• 适合云架构的自动伸缩部署
改善用户体验
挑战
• 需要从校园整体出发，和 ISV 共同 设计业务架构
• 运维管理
• 高校的运维力量相对弱 • 新的技术手段应用有限