What'sTheNextBigThing,Micro?复旦大学刘百祥高校信息化系统架构演变1.Micro?2.微服务是否适合高校？提纲问题一Micro?1.1Micro，微•微服务和微信并不是一件事，此微非彼微•Microservices•Wechat•但后面我其实会讲到它们还真能比较搭配Micro，微？•微服务(Microservices)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成•系统中的各个微服务可被独立部署，各个微服务之间是松耦合的•每个微服务仅关注、并很好地完成一件任务•在所有情况下，每个任务代表着一个小的业务能力Microservices,微服务•部分IT企业开始转向DevOps（Development+Operations）模式•快速交付需求•降低多环境多配置的维护难度•构建轻量化PaaS平台技术的成熟催生了微服务架构技术的发展催生了微服务测试开发运维1.2架构风格演变系统架构模式演化AllinoneVerticalElasticMicro单块架构基本无人使用成本低，但二次开发困难垂直架构有一定模块化负载均衡SOA架构服务管控RPC技术(RomoteProcedureCall)微服务架构高密度部署原子、自治•MonolithicVSMicroservices•单体式架构VS微服务架构•ChrisRichardson的系列介绍文章不同的架构风格传统的架构支付SMSEMail界面应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。微服务架构每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。数据库的组织和依赖模式改变了1.3微服务的优劣优点•模块界限清晰，职责明确•多团队协作变得可行•模块间依赖减少•开发语言•数据库•轻量环境即可支撑•适合云架构的伸缩部署缺点•通信增加•数据交换渠道、交换量•数据一致性复杂•对变更管理提出高要求•多模块配合对运维提出高要求•跨组件的安全管控优劣分析大量通信1.跨服务数据请求2.共享的代码型数据，静态数据（服务化？代码化？复制表？）3.数据约束关系（传统的外键约束不可行）4.传统的一张表会被分裂成多张（对数据重新设计的过程）数据一致性问题•微服务拆分之后，最大的挑战来自于运维、监控、故障处理，如果团队没有微服务运行的经验，故障之后无法快速定位、快速回复，会受到更大的业务压力，因此后期的微服务运营平台或者管理平台对团队异常重要，需要配套设计及时跟上，支撑微服务的运行管理。管理运维问题1.4关于微服务的观点•《ExploringtheDualityBetweenProductandOrganizationalArchitectures》书中给了一个很有意思的观点，组织的耦合度与系统的模块化成正比•微服务架构本质上在强调松耦合的架构，因此在微服务架构迁移前，我们有必要对组织进行微调，确保独立的、小的团队交付一个微服务，同时小团队是微服务的Owner（除了负责开发外，同时负责测试和运维）。这会极大提供团队的责任感，加速微服务的自治和交付能力。组织的耦合度与系统的模块化成正比•微服务的出现应当归功于SOA原则的成功•微服务不再强调使用ESB，转而使用APIGateway•更细粒度的通讯，Restful方式•微服务使用各自为政，去中心式的架构模式微服务VSSOA问题二微服务是否适合高校？2.1高校信息化架构现状•初建：定制、开发平台•共享库：ETL支撑下的多业务系统•门户：应用集合，单点登录•服务门户（一站式服务）我们的系统架构演变面向用户服务的发展方向信息门户•新闻抓取、信息聚合•提供了单向的信息聚合与发布服务应用门户•应用集合、单点登录•集成了个人信息中心、部门数据展示服务门户•服务分类、应用集成•初现了迎新、离校等跨部门服务特征办事服务大厅•流程再造、服务碎片•展现了一站式服务、平台化支持的雏形一站式/智慧校园•主动服务、高效协同•突出了模块化结构、重构业务系统•精力分散于业务梳理工作•不得不依托独立软件开发商（ISV）进行服务•单一厂商绑架•厂商之间协同难度较大•必须依赖于ISV进行交付后的运维工作痛点与方案-人员/技术不足•微服务方式为松耦合架构•独立小型团队可以胜任•灵活选择技术路线•微服...
