微服务架构应用前景研究

一、软件架构的发展历程

互联网发展迅速, 应用规模进一步扩大, 传统架构难以解决现实问题, 微服务架构逐渐普及, 在此期间, 根据系统容量和技术的变化可以分为如下四个阶段。

(1) 单体架构。即单体模式, 所有功能代码整合到一起, 这种开发模式逻辑简单, 有利于对项目的的部署和调试。但这种模式也有不足之处, 由于它将所有功能代码聚集到一起, 这就造成模块之间耦合度高, 难以分离, 不利于各模块间协同工作, 使系统结构模糊, 出现软件系统可维护性低、扩展性差等问题, 这无疑增加了对软件更新、升级的负担。

(2) 垂直架构。随着互联网迅速发展, 网站访问量和待处理数据量迅速上升, 这使网站负载量越来越高, 原单体结构已难以满足需求, 为提高网站服务器与用户交互效率, 可以根据各功能将系统进行拆分, 例如, 将完整的业务需求系统拆分成相互独立的子系统, 使各部分负载均衡, 提高系统容错性, 同时也可增加设备, 将应用业务与数据进行分离, 分别放于不同的服务器, 提高两者效率, 这种架构实现了对各模块优化, 系统流量分担, 并解决了服务器访问并发问题。

(3) SOA架构。伴随着网络负载量的进一步扩大, 以及服务器的增加, 使得整个软件系统结构错综复杂, 依赖关系模糊, 故基于此出现一系列新的理念, 常见的有分布式、集群, 这些技术的共同点都是为了提高数据处理的效率以及系统的容错性, SOA架构也由此产生, 该架构也称为面向服务的架构, 关注点在于服务, 针对不同应用之间的复杂的访问、交互问题, 提供一层服务处理接口, 为不同应用提供不同服务, 将各模块进行解耦, 使不同系统之间更为便捷实现资源共享、服务调用。

(4) 微服务架构。可以看作是SOA架构的进一步优化, 即将各服务组件更细粒度的进行拆分, 进一步对各模块之间进行降耦, 使每一服务对应单一业务, 实现职责单一, 每个服务并不关心该用怎样技术去实现, 做到平台与开发性无关, 提高软件系统的可扩展性, 进一步提高开发效率。

二、微服务原理

微服务架构的主流思想是打破原有单体式架构, 将应用分解为多个相互独立的, 可以互相连接的微服务, 每个微服务完成特定的功能需求, 例如, 在CRM系统中, 客户管理与订单管理可分为两个不同的微服务, 每个微服务拥有自己的业务逻辑和适配器, 微服务之间通过REST API进行通信, 部分微服务也可提供API接口供客户端以及终端用户进行调用, 由于微服务架构的风格将各模块单一化, 只需注重某一单一的功能所对应的微服务组件即可。

(1) 微服务边界。微服务架构风格是从以往架构中演变而来的, 比起科学而言, 更像是一门艺术, 所以要划分好微服务边界就要遵循如下两个规则, 首先要避免随意原则, 确保微服务内部具有高内聚的特点, 这就要求微服务的代码具有较高凝聚力, 还有就是要求各微服务之间应是高度松耦合的, 这样可以避免当修改某一服务时, 还需修改其他服务或影响到其他服务的正常工作, 当服务之间的改变互不影响, 且又相互独立时, 就可以称为高度松耦合, 上述两种规则即为微服务边界划分条件, 两者缺一不可。

(2) 微服务交互。由于微服务之间相互独立, 故每个微服务所用开发技术不同, 数据类型、数据格式也不同, 或者数据库类型不同, 这无疑增加了微服务交互的复杂性, 所以各微服务应遵循相应的规则, 才能保证系统能够有条不紊的进行, 现阶段有三种常见规则, 首先, 读者容错规则, 即读者只需提取发送者所发送的, 自身所需的内容, 而多余或不兼容的内容则选择摒弃, 第二种是契约规则, 即消费者对数据提供者通过契约提供约束, 提供者遵循契约, 从而保证微服务交互的进行, 第三种是数据共享规则, 即微服务之间通过共享缓存或数据库进行数据互通, 上述三种规则均有各自优缺点, 对于微服务之间交互如何约定、遵守, 成为交互规则研究的重中之重。

(3) 微服务部署。在微服务架构模式中, 由于各服务模块粒度小, 相互独立, 造成微服务系统复杂度高, 因此, 在部署微服务系统时, 应格外重视系统的容错性, 这样才能保证微服务系统成功运行, 现如今, 较为流行的微服务产品是Spring项目组中的SpringBoot、SpringCloud, 摒弃了以往配置文件复杂, 繁琐的配置流程等缺点, 可以便捷迅速的构建一个微服务, 使开发人员和设计人员将精力集中到业务需求而非环境配置当中, 这对于部署微服务系统提供很大便利, 在解决实际问题中, 应注重灵活性, 充分利用先进的理念, 如分布式、云计算等思想, 制定相应的部署策略完成微服务系统的搭建。

三、微服务架构优缺点

(一) 微服务架构优点

由于微服务架构将系统高度模块化, 每一微服务部件功能单一, 且相互独立, 使得不会因某一微服务的修改或出错而影响到其他的微服务, 这无疑提高了系统的容错能力, 同时由于微服务之间高度低耦合, 使得每个微服务能够独立部署, 更易于开发工作, 也便于软件的升级、更新。

(二) 微服务架构缺点

由于微服务架构自身特性, 使得在设计过程中会遇到很多复杂的问题, 由于需要更细粒度的划分以及高度低耦合的要求, 在对容错以及微服务组件进行设计时需耗费更多的资源, 另外由于微服务之间高度独立, 采用技术、数据库等各有差异, 这对于微服务间协同、通信是极大的困扰。

四、结束语

以往的单体架构模式只适用于轻量级应用项目, 若项目复杂度高, 若运用以往架构模式则步履维艰, 微服务架构虽设计复杂, 但却是提高应用可扩展性、容错性的一个更好的选择, 微服务架构风格, 不仅是一种趋势, 更是一种挑战, 随着技术的日新月异, 微服务架构会成为普遍的技术开发手段。

摘要：自2014年, 微服务架构概念经Martin Flower提出以来, 受到广泛关注, 为更好了解微服务架构风格, 本文首先分析、梳理了软件架构的发展历程, 随后介绍了微服务架构的原理、设计和目前流行的微服务产品, 并分析其优缺点, 最终对微服务架构的应用前景作出论述。

关键词：软件架构,微服务架构,SpringBoot

参考文献

[1] 张雷, 王悦.基于SpringBoot微服务架构下的MVC模型研究[J].安徽电子信息职业技术学院学报, 2018, 17 (04) :1-9.

[2] 洪华军, 吴建波, 冷文浩.一种基于微服务架构的业务系统设计与实现[J].计算机与数字工程, 2018, 46 (1) :149-154.