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

What'sTheNextBigThing,Micro?复旦大学刘百祥MicroMicro?1.1.1MicroMicro，微.微服务和微信并不是一件事，此微非彼微.Microservices.Wechat.但后面我其实会讲到它们还真能比较搭配MicroservicesMicroservices,微服务.微服务(Microservices)是一种架构风格，一个或多个微服务组成运维运维.部分IT企业开始转向DevOps (Development+Operations)开发测试付需求开发测试低多环境多配置的维护难度.构建轻量化PaaS平台务架构1.1.2务架构治SOA架构RPC技术(务架构治SOA架构RPC技术(RomoteProcedureCall)AllinoneVerticalElasticMicro化使用二.MonolithicVSMicroservices.单体式架构VS微服务架构事件的模块完以及提供API或者UI架构架构型六角自己的业务逻一些微服务还会发布API给户端使赖模式改变了赖模式改变了1.1.3的优劣优点缺点.模块界限清晰，职责明确.通信增加.数据交换渠道、交换量.多团队协作变得可行.数据一致性复杂.模块间依赖减少.开发语言.对变更管理提出高要求.数据库.轻量环境即可支撑.多模块配合对运维提出高要求.适合云架构的伸缩部署.跨组件的安全管控跨服务数据请求据(服务化？代码化？复制表？)3.数据约束关系(传统的外键约束不可行)4.传统的一张表会被分裂成多张(对数据重新设计的过程)会受到更大的平台或者管理平台对团队异常重要，需要配套设计及时跟上，1.1.4模块化成正比.《ExploringtheDualityBetweenProductandOrganizationalArchitectures》书中给了一个很有意思的观点，组织的耦合度与系统的模块化成正比.微服务架构本质上在强调松耦合的架构，因此在微服务同时小团队是微服务的Owner(除了负责开发外，同时负责测试和运维)。微微服务VSSOA.微服务的出现应当归功于SOA原则的成功.微服务不再强调使用ESB，转而使用APIGateway.更细粒度的通讯，Restful方式.微服务使用各自为政，去中心式的架构模式2.2.1.初建：定制、开发平台.门户：应用集合，单点登录.服务门户(一站式服务)信息门户应用门户信息门户应用门户抓取、.提供了单向一站式/智集合、.集成了个示分类、.初现了迎离校再造、.展现了一站形.主动服务、.突出了模块..精力分散于业务梳理工作.不得不依托独立软件开发商 (ISV)进行服务.单一厂商绑架.厂商之间协同难度较大.必须依赖于ISV进行交付后痛点与方案-人员/技术不足..微服务方式为松耦合架构.独立小型团队可以胜任.灵活选择技术路线.微服务改变运维团队工作重心.无需了解巨无霸系统痛点痛点-系统迭代难度大.大量巨无霸、紧耦合(烟囱) (服务商能力有限、人员变更频繁)度大.逐步改善巨无霸系统.改变服务提供方式.从数据视图转换为API.从紧耦合系统中剥离数据构建服务.微服务相对独立.解除耦合.独立伸缩与方案–与方案–数据使用缺乏管理.缺乏审计和安全管控，使用明.跨业务数据调用无统一规范，.依赖核心库，存在性能影响一致(统计规则、代码、时间节点).统一规划设计业务数.使用标准接口.数据独立提供服务.增加状态记录、使用、审平台化Platform平台化Platform•建设平台化系统复旦复旦eHall的模式已经在向轻量化演变.平台化支持流、表单填写、数据交.业务数据和逻辑数据在平.经过简化的单个业务可以.提供虚拟化环境境.提供容器环境2.2.2.需要梳理微服务架构方式.全局考虑全校业务系统和数据.和软件供应商共同设计架构.增强运维能力.自动化测试、持续集成与自动化部署微微服务仍存在挑战–针对校园环境分析.模块界限清晰，职责明确.微服务适合多业务相互配合.校园数据复杂.数据分离有利于数据治理工.架构变更难.过多的历史遗留系统.技术力量薄弱.通信增加.数据交换渠道、数据交换量.数据一致性问题.接口一致性问题微微服务仍存在挑战–针对校园环境分析.团队更灵活.灵活选择轻型服务商.灵活选择技术架构.技术选型灵活.开发语言.数据库.轻量环境即可支撑.适合云架构的自动伸缩部署.需要从校园整体出发，和ISV共同.运维管理.高校的运维力量相对弱.新的技术手段应用有限2.2.3.全校业务系统都会使用到的用户信息.学号-姓名-性别等等.一卡通充值.API同时为微信入口和web提供充值入口服务.业务具有一致性.课程表、成绩服务.为个人数据中心服务微微信、APP、服务门户(eHall).互联网风格的服务入口.横截面型系统.业务横跨多个系统(部门)..复旦将从如下角度.从小型标准服务开始.转换为API方式，.引入日志、审计、权.监控与报警微服务范围用户信息服务全校业务系统日程服务全校业务系统地理信息服务全校业务系统统一消息服务全校业务系统课程信息服务教务、个人数据中心、微成绩信息服务教务、个人数据中心、微支付信息服务(查询)涉及支付业务的系统服务梳理构建测试服服务梳理构建测试服务整理API标准梳理微服梳理微服务模式构建运维平台API管理.API管理.从仅API方式提供数据，到完整的API版本、日志记录、调用分析.从简单授权，到完整的安全管控、多模式授权.采用逐步演化方式进行服务梳理.从单向提供数据，到双向处理.从单一业务系统，到跨业务系统.从小范围，到覆盖全校范围建建设模式.先从改变自主开发系统架构，讨外包系统架构，再到全校业务架构.从复旦实际环境实验，推广至兄弟高校运维管理.先从仅关注服务状态，随后关注伸缩能力.最后引入自动化测试、持续集成与自动化