高校信息化系统架构演变.pptx

高校信息化系统架构演变;提要;问题一;1.1;微服务和微信并不是一件事，此微非彼微 Microservices Wechat 但后面我其实会讲到它们还真能比较搭配;微服务(Microservices)是一个架构格调，一个大型复杂软件应用由一个或多个微服务组成 系统中各个微服务可被独立布署，各个微服务之间是松耦合 每个微服务仅关注、并很好地完成一件任务 在全部情况下，每个任务代表着一个小业务能力 ;个别 IT 企业开始转向 DevOps（Development + Operations）模式 快速交付需求 降低多环境多配置维护难度 构建轻量化 PaaS 平?? 技术成熟催生了微服务架构;1.2;系统架构模式演化;Monolithic VS Microservices 单体式架构 VS 微服务架构 Chris Richardson系列介绍文章 ;传统架构;微服务架构;数据库组织和依赖模式改变了;1.3;优点;大量通信;跨服务数据请求 共享代码型数据，静态数据（服务化？代码化？复制表？） 数据约束关系（传统外键约束不可行） 传统一张表会被分裂成多张（对数据重新设计过程）;微服务拆分之后，最大挑战来自于运维、监控、故障处理，假如团体没有微服务运行经验，故障之后无法快速定位、快速回复，会受到更大业务压力，因今后期微服务运行平台或者管理平台对团体异常主要，需要配套设计及时跟上，支撑微服务运行管理。;1.4;《Exploring the Duality Between Product and Organizational Architectures》书中给了一个很有意思观点，组织耦合度与系统模块化成正比 微服务架构本质上在强调松耦合架构，所以在微服务架构迁移前，咱们有必要对组织进行微调，确保独立、小团体交付一个微服务，同时小团体是微服务Owner（除了负责开发外，同时负责测试和运维）。这会极大提供团体责任感，加速微服务自治和交付能力。 ;微服务出现应该归功于SOA标准成功 微服务不再强调使用 ESB，转而使用 API Gateway 更细粒度通讯，Restful 方式 微服务使用各自为政，去中心式架构模式 ;问题二;2.1;初建：定制、开发平台 共享库：ETL支撑下多业务系统 门户：应用集合，单点登录 服务门户（一站式服务） ; 面向用户服务发展方向;精力分散于业务梳理工作 不得不依靠独立软件开发商（ISV）进行服务 单一厂商绑架 厂商之间协同难度较大 必须依赖于ISV进行交付后运维工作;大量巨无霸、紧耦合（烟囱）系统 模块耦合紧密，运维难度大 组件依赖严重，改造、测试难度大 技术陈旧，更新迟缓，开发周期长（服务商能力有限、人员变更频繁）;逐步改进巨无霸系统 改变服务提供方式 从数据视图转换为 API 从紧耦合系统中剥离数据构建服务 微服务相对独立 解除耦合 独立伸缩;缺乏审计和安全管控，使用情况不明 跨业务数据调用无统一规范，存在故障隐患 依赖关键库，存在性能影响 数据取自不一样系统，结果不一致（统计规则、代码、时间节点）;用互联网方式服务用户 多终端、多场景 简化用户工作，重梳理业务流程 建设平台化系统 工作流、统一消息、统一报表;平台化支持 工作流、表单填写、数据交换、应用门户 业务数据和逻辑数据在平台间传递 经过简化单个业务能够脱离传统业务运行;提供虚拟化环境 去小机已经基础完成 大量业务系统运行于虚拟化环境 提供容器环境 正在进行容器平台评定工作 ;2.2;需要梳理微服务架构方式 全局考虑全校业务系统和数据 支撑业务暴发、快速交付等能力 和软件供给商共同设计架构 增强运维能力 自动化测试、连续集成与自动化布署;优点;优点;2.3;全校业务系统都会使用到用户信息 学号-姓名-性别等等 复旦来自LDAP，并不一定准确 都交给关键库？ ;一卡通充值 API 同时为微信入口和 web 提供充值入口服务 业务含有一致性 但并未彻底服务化，API 并不完善 ;课程表、成绩服务 多么好标准服务格调 为个人数据中心服务 为微信服务、APP、H5 是否可能开放给学生写自己课程表？;互联网格调服务入口 横截面型系统 数据横跨多个系统 业务横跨多个系统（部门） ;复旦尝试;计划实施路径;采取逐步演化方式进行;Microservices 微服务应该能处理很多问题 也带来很多挑战 技术并非关键，切实处理眼前实际工作需求才是出发点 以上是复旦关于微服务一些思索，咱们已经开始进行研究工作，也欢迎弟兄院校共同探讨。 ;