SYS SECURITY 系统安全
浅谈微服务架构的网站开发技术
◆ 姚 刚 蔡凤翔 李英浩
摘要：随着互联网技术的普及和发展，软件开发技术同样发展迅速。近些年来，以微服务架构的软件开发技术异常火热，以至于用来构建微服务的Netflix、Dubbo、Spring Cloud等产品也变得十分活跃。论文阐述微服务开发的概念、微服务开发、以及构建微服务网站开发的模式等三个方面论述了基于微服务架构的网站开发技术。
关键词：微服务；网站开发；技术
一、微服务开发
微服务的概念早在2014年就已经被提出，经过多年的发展其理论体系和开发方法日益成熟，并在业界得到广泛地应用。微服务就是把一个完整的应用从数据存储，到业务逻辑开发，自下而上垂直分割成多个不同的服务单元，每个单元都有与其他单元不同的职责，这些单元称其为单一职责小服务，也就是“微服务”。各服务单元地存在于这个大系统中，每个服务都仅运行在自己的进程中，这些进程与其他服务的进程互不影响、互不干扰，各服务之间的通信是通过一个共同的协议来实现，这个协议就是API协议。所有这些服务的开发可以使用相同编程语言，也可以使用不同的编程语言；可以使用相同或不同的存储技术；并且所有的服务都能够进行自动，且的完成部署；同时保持着最低的集中管理模式。
微服务是一种软件开发架构设计模式。在这种架构中，各服务被组件化，由各组件共同构成一个完整的业务逻辑和一个较大的应用体系。体系中的每一个组件，即一个单元，就是一个“微服务”。所有的微服务都单独执行着各自的任务，但是微服务并不是孤立地存在，各服务相互之间同时会被其他一个或多个服务调用，各服务间通过约定的协议集合在一起，共同完成一个具体的任务，实现软件业务需求或产品开发等。目前微服务的开发框架最常用的有Spring Cloud/Spring Boot、Dubbo、Dropwizard、Consul四种。
二、微服务开发应用场景
在软件开发过程中，什么时候需要用微服务进行开发呢？我们首先要了解微服务有哪些优缺点。微服务具有鲜明的优点：开发简单且效率高；每个服务足够内聚，比较容易聚焦；微服务是松耦合的，无论开发还是部署都可以完成；微服务可以用不同的语言开发；易于和第三方集成；微服务允许容易且灵活的自动集成部署；另外，微服务容易被开发人员理解、修改和维护等。同样微服务并不是无所不能的理论，也有其明显的缺点：开发人员要处理分布式系统的复杂性，较为依赖系统部署，数据的一致性，性能监控的难度，以及服务间通讯的成本等，另外，多服务运维难度和随着服务的增加运维的压力也会增大。落地微服务架构，重点就是发扬优点，克服缺点。因此，是否采用微服务进行软
件开发，首先需要有明确的目的，对微服务的优缺点要有清晰的认知。
微服务的这些特点决定了其适用范围和应用场景。如果用单体应用能轻松解决的问题就没必要用微服务架构。只有遇到有分布式、弹性扩展等需求的情况，才需要考虑使用微服务开发。一个微服务我们可以认为它是一个小的单体应用，在有很多单体应用之间需要通信和协同的情况下，或者通过单体应用之间的集成无法满足业务性能要求，需要重构业务应用系统时，才需要考虑采用微服务开发，微服务意在重构。通常在大中型企业有众多的单体业务系统的情况下，并且各单体业务应用集成可能成为一个问题的时候，需要考虑采用微服务架构重构业务应用。由于微服务架构体系需要众多的基础设施平台和基础组件支撑，才能发挥微服务架构的优势，所以对于一些小公司或者在基础设施比较落后的情况下，采用微服务可能无法展现其价值，反而使管理任务变得更多、更繁琐。
服务化的目的在于重用，微服务也是同样。无论函数化、模块化、组件化、服务化等，它们最重要的目的在于共享和重用。微服务具有分布式弹性的特点，微服务的实例数弹性伸缩，可以和容器平台结合，利用容器弹性伸缩的特性，实现微服务地弹性，快速响应业务变化地需求。
采用微服务往往也是因为其轻量，可以快速迭代，即时响应新业务需求，快速开发部署微服务应用，在抢占市场的同时可以持续的迭代和完善。所以采用微服务的网站开发通常是以业务需求变化的速度快这一场景为起始，比如产品促销类活动等，然后逐步推广到其他业务场景。
三、构建微服务网站开发的模式
微服务架构的网站开发实现相对于单体架构变得更简单、更容易。因此微服务极大地降低了系统的复杂性，使系统开发工作变得简单易行。
（一）使用微服务进行开发的基本过程[1]
1.使用开发者现有的技术能力，开发具有单一业务功能的微服务。
2.在注册中心，提供方负责把地址信息放进去，服务方负责调用获取。
3.移动 APP或网站门户获取由服务网关提供的API。
信息系统工程 │ 2019.12.20
69
SYS SECURITY 系统安全4.最后对管理端模块进行集成。
在微服务架构中引入基于Spring Boot的security starter，security starter包含了Banner。UPMS中存放着微服务的访问地址信息，以及功能菜单、角色权限等信息。当用户需要打开一个微服务，展示微服务页面，其实这个过程就是UPMS的API获取微服务的功能列表，以及服务清单让security starter去调用地过程。如图1所示，微服务应用架构图。
图1 微服务应用架构图
（二）为了实现以上四点，相对应以下必需的组件[1] 1.注册中心、服务发现、负载均衡，对应上边第一步与第二步。在微服务中服务注册是为了实现那些职责单一的细粒度的服务进行通信而引入的模块，服务注册地引入是为了方便各服务间的调用与访问。当服务的获取方从注册中心调用某个服务地址的时候，服务的推送方需要把服务地址放到这个中心，这个注册中心就叫Service Registry Center。同时，负载均衡的引入很好地解决了微服务以集群方式提供服务遇到的诸多问题。
2.服务网关，对应开发过程的第三步。多个职责任务单一的微服务构成一个较大的系统。在服务调用中，认证权限，以及聚合和剪裁数据等工作通过API网关完成。当系统需要调用API时，至少需要一个这样的服务网关去实现调用过程。
3.管理端的集成，对应上边第四步。管理端给后台运营人员使用。由于后端运营系统的压力不大，我们可以把独自开发的微服务通过CAS和UPMS进行整理或合并。
（三）微服务的集成过程
UPMS的API被Security Starter调用的过程是微服务的所有一级菜单和当前微服务的二级菜单被调用的过程，就是用户从浏览器或APP开发一个微服务的过程，在这个过程中微服务的页面通过这个过程呈现给该用户使用。这里的一级菜单是指微服务清单，二级菜单是指功能清单。单体应用被微服务化后，程序包从原来的一个包分成了许多个包，因此部署工作会直接扩大至几何倍数。但是Docker容器技术很好地解决了这类问题，它可以将系统中的微服务进行不需要人为干预的部署和不间断地持续集成，集成变的简单易行。
经过以上步骤，就可以完成一个简单模式的基于微服务架构的系统。如图2所示，简单模式微服务架构系统图。
70信息系统工程 │ 2019.12.20
图2 简单模式微服务架构系统图
相对于大型网站巨大的并发用户访问数量，对于大多数公司来说都不会有这样的需求，他们更关注的是在开发过程中怎样提高开发速度，如何解决各类新需求的时效性，如何节约开发成本与损耗，以及网站的后期运维等问题。这种简单模式的微服务架构方案可以很好地解决这一类问题，满足一般公司所关注的问题。基于微服务的简单模式只需要对注
册中心、服务网关和负载均衡等进行关注，不需要关注开发、测试、API调用等问题，以及数据的一致性技术和各类组件等。
四、结语
随着WEB应用程序和云计算技术的发展，单体架构应用程序变的越来越庞大，且越来越复杂，使系统的可伸缩性、可扩展性和可维护性在不断降低。为了应对这个挑战，我们引入了微服务开发的概念。对于业务需求变化快，需求具有弹性扩展性特点的网站开发而言，我们通过把一个巨大的单体分解为多个微服务的方法，很好地解决了网站开发复杂性，以及后续运维难度等问题。微服务架构中的每个服务都地存在于这个系统中，这种架构模式允许每个服务可以由特定的开发团队独自开发，对于开发技术或何种语言的选择，开发团队和开发人员可以根据自己掌握的软件开发技能自主选择，软件开发过程变得非常灵活和自由。由于各服务是单独的开发，所以允许各服务可以单独的去部署，并且可以根据服务的规模完成具体部署，集成工作也变的更容易实现。因此，微服务的开发人员不在像传统的开发人员那样过多地关注于对其他开发者或服务的调用与协调，考虑各团队或服务之间的相互影响等问题。
通过论述我们可以看出，微服务对提高网站开发的效率，解决具有时效性的新需求，以及网站后期运维等问题提供了很好的解决方案，但微服务也不是放之四海而皆准的理论，有其适用范围，只有充分地认识到了微服务优缺性，才能够开发出适用于公司业务特点的网站系统。H参考文献
[1] 李苏璇. 基于微服务架构的SaaS 应用构建方法研究[D].华南
理工大学,2016 年.
（作者单位：中国石油勘探开发研究院西北分院）
