云原生应用架构在高校信息化建设中的实践

1、 云原生应用架构在高校信息化建设中的实践目 录 TOC o 1-3 h z u HYPERLINK l _Toc60739876 1.云原生概述 PAGEREF _Toc60739876 h 3 HYPERLINK l _Toc60739877 2.组织与赋权 PAGEREF _Toc60739877 h 3 HYPERLINK l _Toc60739878 3.敏捷性基础架构 PAGEREF _Toc60739878 h 3 HYPERLINK l _Toc60739879 4.持续交付 PAGEREF _Toc60739879 h 4 HYPERLINK l _Toc60739880 5.

2、微服务 PAGEREF _Toc60739880 h 6 HYPERLINK l _Toc60739881 6.问题与挑战 PAGEREF _Toc60739881 h 9云原生概述云原生(Cloud Native)概念是由Pivotal的Matt Stine在2013年首次提出的。这个概念得到了各方的不断完善，内容越来越丰富，目前已经包括了DevOps(Development和Operations的组合)、持续交付(Continuous Delivery，CD)、微服务(Micro Services)、敏捷基础设施(Agile Infrastructure)和十二要素(The Twelve-

3、Factor App)等几大主题。这个概念不但包括根据业务能力对企业(高校)进行文化、组织架构的重组与建设，也包括方法论和原则，以及具体的操作工具。采用基于云原生的技术和管理方法，可以更好地从云中诞生业务，也可以把业务迁移到不同的云中，从而享受云的高效与持续服务的能力。组织与赋权云原生架构的应用，不仅仅是技术的应用，还需要组织架构的调整，尤其是在高校，信息化部门的职责和组织架构都需要进行调整。上海海事大学信息化办公室在2016年对组织架构进行了调整，新成立了负责信息系统构建和运营的广义数据中心部门。该部门重新修订了校内与信息应用系统建设相关规章制度，梳理了现有业务系统和各类资源，并从上到下获得

4、管理的职权，从而为云原生架构开发业务系统提供了制度保障、权力保障。敏捷性基础架构顾名思义，云原生是面向云而设计的架构，因此技术部分依赖于云计算的三层模型（IaaS、PaaS和SaaS）。为此，在部门成立时，学校把狭义的硬件数据中心管理职能从网络和基础设施部门中脱离，划入到数据中心部门。为了适应云原生架构，以及高效简易地管理，学校对狭义的数据中心进行了敏捷性改造，并在2017年完全实现了软件定义的数据中心（Software Defined Data Center，SDDC），为云原生应用架构打下了坚实的敏捷基础。这意味着开发人员可以随时获取一套基础设施来服务于开发、测试、联调和灰度上线等需求。持

5、续交付图1 持续交付流程为了满足业务需求变动，通过快速迭代，产品能够做到随时都能发布，上海海事大学研究了一系列开发实践方法，包括持续集成、持续部署、持续发布。学校在内部部署了GitLab系统，除了大规模第三方购买的软件外，学校将定制化开发的代码托管在自己的Git代码库中。GitLab支持自动CI/CD，并且支持Kubernetes集群，这为软件系统的部署提供了最大程度地自动化和最小的成本代价。基本架构可以参看图1。举例来说，学校数字门户是基于著名开源内容管理框架Drupal开发的。学校要求开发公司将代码托管在学校的代码库中，并配置了一台测试环境。在系统需要更新时，必须在测试环境上先验、演示无误

6、后方可自动更新至生产环境；而在后续运维中，无论是安全补丁还是代码优化，都必须采取该种模式。自动部署到生产环境中的工作无需人工操作，全部由代码实现。最终形成了如图2所示的持续交付流程，这也践行了DevOps。图2 海大Portal持续交付流程微服务云原生架构离不开微服务。2013年，大神Martin Flower对微服务概念进行了比较系统的理论阐述，总结了相关技术特征，加速了微服务的应用普及。微服务最直观的理念是采用了Unix的设计哲学-每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务，且又可以通过一系列管道集成在一起发挥巨大作用。对企业来说，微服务不是银弹，企业也享有不多的

7、决策权力（更多的是在软件开发商那里），而且微服务多了后，还需要再有一套规章制度来约束保障服务运转正常，正如数据需要治理一样，微服务多了后也需要微服务治理。而这些都是代价。本书建议有选择性地采用微服务，只有在必须使用时，或者是可以自主抽象为API的场景下才选择微服务。无论如何，微服务的目录清单是必须且是对内公开的。1案例：附件预览功能在微服务的应用决策策略上，通过一个例子来跟大家介绍一下。为了能够让师生直接在线查看附件，学校需要一个组件，可以把用户上传的附件转成HTML文件，实现在线预览。但是学校的平台（需求方）是PHP语言编写的，而在该语言下没有渲染很好的组件，只有在.Net或者Java编程语

8、言下才有较好的组件，为此只有选择HTTP API方式提供该项功能，这就有了微服务实例的初步模型。在之后，一网通办也需要文件预览，学校通过该API提供了服务。在此之后，PDF合并功能需求以及PDF加密等功能需求逐步增多。而且随着需求方的增多，性能需求也逐步提高，在不知不觉中，逐步实现了横向扩展，逐步迁移到了新环境，逐步增加了缓存，逐步增加了日志，再后来学校就意识到已经具备了微服务12要素的大部分了，干脆就再完善一下，彻底成为微服务吧。2案例：一网通办中的查收查引业务图3 查收查引流程的微服务调用过程再举一个图3所示的API服务案例。学校在一网通办中提供了查收查引流程，该流程的作用主要是图书馆查新

9、工作人员为师生提供查收查引证明服务，线下的处理方式是老师提交了申请材料，图书馆人员进行检索后出具纸质证明材料，师生根据需要再扫描后录入到其他系统中。而学校在一网通办中的流程则把打印、盖章、扫描过程进行了电子化，免去师生跑腿的麻烦。但是在技术上如何实现呢？固然可以再购买组件，然后用Java语言进行开发，但是学校研究后发现原先购买的组件已经通过HTTP API提供了相关服务。若是通过修改代码实现代码级复用也是一种方案，但是学校更倾向于Node.js架构的轻量级开发，直接通过Java Script编排微服务调用会是一种更好的选择。因此最终学校又多实现了一个为PDF做电子签章（生效范围仅限校内应用系统的电子签章）的HTTP API微服务实例，然后在一个js文件中编排了相关的微服务调用，实现了预期功能。问题与挑战尽管云原生架构给业务系统开发和运维带来了便利，但是企业也不得不思考它的应用场景、实施代价。首先，云原生架构和微服务一直