高校信息化系统架构演变-复旦大学

1、Whats The Next Big Thing,Whats The Next Big Thing, MicroMicro? ?复旦大学 刘百祥高校信息化系统架构演变1.Micro?2.微服务是否适合高校？微服务是否适合高校？提纲问题一Micro?Micro? 1.1MicroMicro，微微服务和微信并不是一件事，此微非彼微 Microservices Wechat但后面我其实会讲到它们还真能比较搭配Micro，微？微服务(Microservices)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成 系统中的各个微服务可被独立部署，各个微服务之间是松耦合的 每个微服务仅关注、并很好

2、地完成一件任务 在所有情况下，每个任务代表着一个小的业务能力Microservices, 微服务部分 IT 企业开始转向 DevOps（Development + Operations）模式 快速交付需求 降低多环境多配置的维护难度 构建轻量化 PaaS 平台 技术的成熟催生了微服务架构技术的发展催生了微服务测试测试开发开发运维运维1.2架构风格演变系统架构模式演化All in oneVerticalElasticMicro单块架构基本无人使用成本低，但二次开发困难垂直架构有一定模块化负载均衡SOA架构服务管控RPC技术(Romote Procedure Call)微服务架构高密度部署原子、自

3、治Monolithic VS Microservices单体式架构 VS 微服务架构Chris Richardson的系列介绍文章不同的架构风格传统的架构支付SMSEMail界面应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。微服务架构每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。数据库的组织和依赖模式改变了1.3微服务的优劣优点 模块界限清晰，职责明确 多团队协作变得可行 模块间依赖减

4、少 开发语言 数据库 轻量环境即可支撑 适合云架构的伸缩部署缺点 通信增加 数据交换渠道、交换量 数据一致性复杂 对变更管理提出高要求 多模块配合对运维提出高要求 跨组件的安全管控优劣分析大量通信1.跨服务数据请求2.共享的代码型数据，静态数据（服务化？代码化？复制表？）3.数据约束关系（传统的外键约束不可行）4.传统的一张表会被分裂成多张（对数据重新设计的过程）数据一致性问题微服务拆分之后，最大的挑战来自于运维、监控、故障处理，如果团队没有微服务运行的经验，故障之后无法快速定位、快速回复，会受到更大的业务压力，因此后期的微服务运营平台或者管理平台对团队异常重要，需要配套设计及时跟上，支撑微服

5、务的运行管理。管理运维问题1.4关于微服务的观点Exploring the Duality Between Product and Organizational Architectures书中给了一个很有意思的观点，组织的耦合度与系统的模块化成正比微服务架构本质上在强调松耦合的架构，因此在微服务架构迁移前，我们有必要对组织进行微调，确保独立的、小的团队交付一个微服务，同时小团队是微服务的Owner（除了负责开发外，同时负责测试和运维）。这会极大提供团队的责任感，加速微服务的自治和交付能力。组织的耦合度与系统的模块化成正比微服务的出现应当归功于SOA原则的成功微服务不再强调使用 ESB，转而使用

6、 API Gateway更细粒度的通讯，Restful 方式微服务使用各自为政，去中心式的架构模式微服务 VS SOA问题二微服务是否适合高校？2.1高校信息化架构现状初建：定制、开发平台共享库：ETL支撑下的多业务系统门户：应用集合，单点登录服务门户（一站式服务）我们的系统架构演变 面向用户服务的发展方向信息门户 新闻抓取、信息聚合 提供了单向的信息聚合与发布服务应用门户 应用集合、单点登录 集成了个人信息中心、部门数据展示服务门户 服务分类、应用集成 初现了迎新、离校等跨部门服务特征办事服务大厅 流程再造、服务碎片 展现了一站式服务、平台化支持的雏形一站式/智慧校园 主动服务、高效协同 突

7、出了模块化结构、重构业务系统精力分散于业务梳理工作不得不依托独立软件开发商（ISV）进行服务 单一厂商绑架 厂商之间协同难度较大必须依赖于ISV进行交付后的运维工作痛点与方案 - 人员/技术不足微服务方式为松耦合架构 独立小型团队可以胜任 灵活选择技术路线微服务改变运维团队工作重心 无需了解巨无霸系统 大量巨无霸、紧耦合（烟囱）系统模块耦合紧密，运维难度大组件依赖严重，改造、测试难度大技术陈旧，更新缓慢，开发周期长（服务商能力有限、人员变更频繁）痛点 - 系统迭代难度大逐步改善巨无霸系统 改变服务提供方式 从数据视图转换为 API 从紧耦合系统中剥离数据构建服务 微服务相对独立 解除耦合 独立

8、伸缩方案 系统迭代难度大缺乏审计和安全管控，使用情况不明跨业务数据调用无统一规范，存在故障隐患依赖核心库，存在性能影响数据取自不同系统，结果不一致（统计规则、代码、时间节点）痛点与方案 数据使用缺乏管理统一规划设计业务数据的隔离模式使用标准接口数据独立提供服务增加状态记录、使用分析、安全控制、审计等功能 用互联网方式服务用户 多终端、多场景 简化用户工作，重梳理业务流程 建设平台化系统 工作流、统一消息、统一报表服务模式与建设方式转型平台化Platform标准化Standardization模块化Modularization通用化Universalization平台化支持 工作流、表单填写、数

9、据交换、应用门户业务数据和逻辑数据在平台间传递经过简化的单个业务可以脱离传统业务运行复旦eHall 的模式已经在向轻量化演变提供虚拟化环境 去小机已经基本完成 大量业务系统运行于虚拟化环境提供容器环境 正在进行容器平台的评估工作环境基础2.2高校如何引入微服务需要梳理微服务架构方式 全局考虑全校业务系统和数据 支撑业务爆发、快速交付等能力 和软件供应商共同设计架构增强运维能力 自动化测试、持续集成与自动化部署高校如何引入微服务架构优点 模块界限清晰，职责明确 微服务适合多业务相互配合的场景 校园数据复杂 数据分离有利于数据治理工作进行挑战 架构变更难 过多的历史遗留系统 技术力量薄弱 通信增加

10、 数据交换渠道、数据交换量 数据一致性问题 接口一致性问题微服务仍存在挑战 针对校园环境分析提升信息化工作效率对数据分离模式、API 设计模式等提出要求优点 团队更灵活 灵活选择轻型服务商 灵活选择技术架构 技术选型灵活 开发语言 数据库 轻量环境即可支撑 适合云架构的自动伸缩部署挑战 需要从校园整体出发，和 ISV 共同设计业务架构 运维管理 高校的运维力量相对弱 新的技术手段应用有限微服务仍存在挑战 针对校园环境分析对架构设计原则、运维管理模式等提出要求改善用户体验2.3从哪里开始? ?全校业务系统都会使用到的用户信息学号-姓名-性别等等复旦来自LDAP，并不一定准确都交给核心库？以实际例

11、子讨论一卡通充值 API 同时为微信入口和 web 提供充值入口服务 业务具有一致性但并未彻底服务化，API 并不完善以实际例子讨论课程表、成绩服务 多么好的标准服务风格 为个人数据中心服务 为微信服务、APP、H5 是否可能开放给学生写自己的课程表？以实际例子讨论互联网风格的服务入口横截面型系统 数据横跨多个系统 业务横跨多个系统（部门）微信、APP、服务门户（eHall）复旦的尝试微服务微服务范围范围用户信息服务用户信息服务全校业务系统全校业务系统日程服务日程服务全校业务系统全校业务系统地理信息服务地理信息服务全校业务系统全校业务系统统一消息服务统一消息服务全校业务系统全校业务系统课程信息

12、服务课程信息服务教务、个人数据中心、微教务、个人数据中心、微信、信、APP等等成绩信息服务成绩信息服务教务、个人数据中心、微教务、个人数据中心、微信、信、APP等等支付信息服务支付信息服务(查询查询)支付平台、微信、支付平台、微信、APP、涉及支付业务的系统涉及支付业务的系统复旦将从如下角度开始尝试 从小型标准服务开始 转换为 API 方式，稳定设计 引入日志、审计、权限等 监控与报警服务梳理服务梳理构建测试构建测试服务服务整理整理API标准标准构建运维构建运维平台平台梳理微服梳理微服务模式务模式计划的实施路径采用逐步演化方式进行服务梳理服务梳理 从单向提供数据，到双向处理从单向提供数据，到双向处理 从单一业务系统，到跨业务系统从单一业务系统，到跨业务系统 从小范围，到覆盖全校范围从小范围，到覆盖全校范围API管理管理 从仅从仅API 方式提供数据，到完整的方式提供数据，到完整的API 版本、日志记录、调用分析版本、日志记录、调用分析 从简单授权，到完整的安全管控、多模式授权从简单授权，到完整的安全管控、多模式授权运维管理运维管理 先从仅关注服务状态，随后关注伸缩能力先从仅关注服务状态，随后关注伸缩能力 最后引入最后引入自动化测试、持续集成与自动化部署自动化测试、持续集成与自动化部署建设模式建设模式 先从改变自主开发系统架构，和先从改变自主开发系统架构，和 ISV 共