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

来源：

上海海事大学

2020-05-18 13:55:00

　　云原生

　　云原生(Cloud Native)概念是由Pivotal的Matt Stine在2013年首次提出的。这个概念得到了各方的不断完善，内容越来越丰富，目前已经包括了DevOps(Development和Operations的组合)、持续交付(Continuous Delivery，CD)、微服务(Micro Services)、敏捷基础设施(Agile Infrastructure)和十二要素(The Twelve-Factor App)等几大主题。这个概念不但包括根据业务能力对企业(高校)进行文化、组织架构的重组与建设，也包括方法论和原则，以及具体的操作工具。采用基于云原生的技术和管理方法，可以更好地从云中诞生业务，也可以把业务迁移到不同的云中，从而享受云的高效与持续服务的能力。

　　组织与赋权

　　云原生架构的应用，不仅仅是技术的应用，还需要组织架构的调整，尤其是在高校，信息化部门的职责和组织架构都需要进行调整。上海海事大学信息化办公室在2016年对组织架构进行了调整，新成立了负责信息系统构建和运营的广义数据中心部门。该部门重新修订了校内与信息应用系统建设相关规章制度，梳理了现有业务系统和各类资源，并从上到下获得管理的职权，从而为云原生架构开发业务系统提供了制度保障、权力保障。

　　敏捷性基础架构

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

　　持续交付

图1 持续交付流程

　　为了满足业务需求变动，通过快速迭代，产品能够做到随时都能发布，上海海事大学研究了一系列开发实践方法，包括持续集成、持续部署、持续发布。学校在内部部署了GitLab系统，除了大规模第三方购买的软件外，学校将定制化开发的代码托管在自己的Git代码库中。GitLab支持自动CI/CD，并且支持Kubernetes集群，这为软件系统的部署提供了最大程度地自动化和最小的成本代价。基本架构可以参看图1。

　　举例来说，学校数字门户是基于著名开源内容管理框架Drupal开发的。学校要求开发公司将代码托管在学校的代码库中，并配置了一台测试环境。在系统需要更新时，必须在测试环境上先验、演示无误后方可自动更新至生产环境；而在后续运维中，无论是安全补丁还是代码优化，都必须采取该种模式。自动部署到生产环境中的工作无需人工操作，全部由代码实现。最终形成了如图2所示的持续交付流程，这也践行了DevOps。

图2 海大Portal持续交付流程

　　微服务

　　云原生架构离不开微服务。2013年，大神Martin Flower对微服务概念进行了比较系统的理论阐述，总结了相关技术特征，加速了微服务的应用普及。微服务最直观的理念是采用了Unix的设计哲学--每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务，且又可以通过一系列管道集成在一起发挥巨大作用。对企业来说，微服务不是银弹，企业也享有不多的决策权力（更多的是在软件开发商那里），而且微服务多了后，还需要再有一套规章制度来约束保障服务运转正常，正如数据需要治理一样，微服务多了后也需要微服务治理。而这些都是代价。本书建议有选择性地采用微服务，只有在必须使用时，或者是可以自主抽象为API的场景下才选择微服务。无论如何，微服务的目录清单是必须且是对内公开的。

　　1．案例：附件预览功能

　　在微服务的应用决策策略上，通过一个例子来跟大家介绍一下。为了能够让师生直接在线查看附件，学校需要一个组件，可以把用户上传的附件转成HTML文件，实现在线预览。但是学校的平台（需求方）是PHP语言编写的，而在该语言下没有渲染很好的组件，只有在.Net或者Java编程语言下才有较好的组件，为此只有选择HTTP API方式提供该项功能，这就有了微服务实例的初步模型。在之后，“一网通办”也需要文件预览，学校通过该API提供了服务。在此之后，PDF合并功能需求以及PDF加密等功能需求逐步增多。而且随着需求方的增多，性能需求也逐步提高，在不知不觉中，逐步实现了横向扩展，逐步迁移到了新环境，逐步增加了缓存，逐步增加了日志，再后来学校就意识到已经具备了微服务12要素的大部分了，干脆就再完善一下，彻底成为微服务吧。

　　2．案例：“一网通办”中的“查收查引”业务

图3 查收查引流程的微服务调用过程

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

　　困难

　　尽管云原生架构给业务系统开发和运维带来了便利，但是企业也不得不思考它的应用场景、实施代价。首先，云原生架构和微服务一直在发展，各种软件、各种实现层出不穷，给本就人员不多待遇很低的高校信息化教师带来很大的学习压力；其次，无论是敏捷的基础架构，还是灵活的微服务架构，都需要高水平架构师，并且是精力持续旺盛的架构师，看看云原生架构全景图就知道它的复杂度了；再次，这不是高校信息办一个部门能够决定的，这是一个生态圈的问题。

　　当然，在实施过程中企业还应该避免过分的教条主义，还是要灵活多变，借鉴其中的思想精髓就足够了。