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

高校信息化系统架构演变Whats The Next Big Thing, Micro?复旦大学 刘百祥提纲Micro? 问题一Micro，微1.1Micro，微？微服务和微信并不是一件事，此微非彼微MicroservicesWechat但后面我其实会讲到它们还真能比较搭配Microservices, 微服务微服务(Microservices)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成系统中的各个微服务可被独立部署，各个微服务之间是松耦合的每个微服务仅关注、并很好地完成一件任务在所有情况下，每个任务代表着一个小的业务能力技术的发展催生了微服务部分 IT 企业开始转向 DevOps（Development + Operations）模式快速交付需求降低多环境多配置的维护难度构建轻量化 PaaS 平台 技术的成熟催生了微服务架构开发测试运维架构风格演变1.2系统架构模式演化All in oneVerticalElasticMicro单块架构基本无人使用成本低，但二次开发困难SOA架构服务管控RPC技术(Romote Procedure Call)垂直架构有一定模块化负载均衡微服务架构高密度部署原子、自治不同的架构风格Monolithic VS Microservices单体式架构 VS 微服务架构Chris Richardson的系列介绍文章传统的架构应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。SMS界面EMail支付微服务架构每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。数据库的组织和依赖模式改变了微服务的优劣1.3优劣分析缺点优点通信增加数据交换渠道、交换量数据一致性复杂对变更管理提出高要求多模块配合对运维提出高要求跨组件的安全管控模块界限清晰，职责明确多团队协作变得可行模块间依赖减少开发语言数据库轻量环境即可支撑适合云架构的伸缩部署大量通信数据一致性问题跨服务数据请求共享的代码型数据，静态数据（服务化？代码化？复制表？）数据约束关系（传统的外键约束不可行）传统的一张表会被分裂成多张（对数据重新设计的过程）管理运维问题微服务拆分之后，最大的挑战来自于运维、监控、故障处理，如果团队没有微服务运行的经验，故障之后无法快速定位、快速回复，会受到更大的业务压力，因此后期的微服务运营平台或者管理平台对团队异常重要，需要配套设计及时跟上，支撑微服务的运行管理。关于微服务的观点1.4组织的耦合度与系统的模块化成正比《Exploring the Duality Between Product and Organizational Architectures》书中给了一个很有意思的观点，组织的耦合度与系统的模块化成正比微服务架构本质上在强调松耦合的架构，因此在微服务架构迁移前，我们有必要对组织进行微调，确保独立的、小的团队交付一个微服务，同时小团队是微服务的Owner（除了负责开发外，同时负责测试和运维）。这会极大提供团队的责任感，加速微服务的自治和交付能力。微服务 VS SOA微服务的出现应当归功于SOA原则的成功微服务不再强调使用 ESB，转而使用 API Gateway更细粒度的通讯，Restful 方式微服务使用各自为政，去中心式的架构模式微服务是否适合高校？问题二高校信息化架构现状2.1我们的系统架构演变初建：定制、开发平台共享库：ETL支撑下的多业务系统门户：应用集合，单点登录服务门户（一站式服务） 面向用户服务的发展方向痛点与方案 - 人员/技术不足微服务方式为松耦合架构独立小型团队可以胜任灵活选择技术路线微服务改变运维团队工作重心无需了解巨无霸系统精力分散于业务梳理工作不得不依托独立软件开发商（ISV）进行服务单一厂商绑架厂商之间协同难度较大必须依赖于ISV进行交付后的运维工作痛点 - 系统迭代难度大大量巨无霸、紧耦合（烟囱）系统模块耦合紧密，运维难度大组件依赖严重，改造、测试难度大技术陈旧，更新缓慢，开发周期长（服务商能力有限、人员变更频繁）方案 – 系统迭代难度大逐步改善巨无霸系统改变服务提供方式从数据视图转换为 API从紧耦合系统中剥离数据构建服务微服务相对独立解除耦合独立伸缩痛点与方案 – 数据使用缺乏管理缺乏审计和安全管控，使用情况不明跨业务数据调用无统一规范，存在故障隐患依赖核心库，存在性能影响数据取自不同系统，结果不一致（统计规则、代码、时间节点）统一规划设计业务数据的隔离模式使用标准接口数据独立提供服务增加状态记录、使用分析、安全控制、审计等功能服务模式与建设方式转型用互联网方式服务用户多