招标采购系统向微服务架构演进的原因

Posted 2021-04-14 7sh科技

一、电子招投标系统发展

随着网络技术的不断发展，电子招标采购系统的建设逐步取代了传统的现场招投标的方式。电子招标采购信息化系统在打破物理时空屏障的同时，增强了信息透明度，投标方能通过网络获取招标信息，参加招投标活动，提升了工作效率，降低了成本。

初期在电子招投标系统访问量很小的时候，采用单体应用架构，只需要一个war包，将所有的功能都部署在一起，以减少部署节点和成本。

随着电子招投标系统的发展，系统功能及访问量的增加，单体应用架构已不能满足企业发展的需要。根据MVC框架，将单体应用根据功能拆分成几个互不相干的应用，以提升效率，此时称为垂直应用架构。

随着垂直应用的增多，应用中的重复代码也越来越多，应用之间的交互也不可避免，此时将核心功能抽取出来形成单独的应用供其他应用访问，而这一的架构称为分布式服务架构（RPC）。

随着抽取的应用越来越多，应用之间的资源调度、治理成为问题。此时便需要将应用进行拆分与整合，采用微服务架构进行治理、调度。那么下面我们分别来分析下传统电子招标采购系统的单体应用架构与如今主流的微服务架构的相关特点。

二、单体应用架构

一个归档包（例如war格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构。

单体应用比较容易部署、测试，在项目的初期，单体应用可以很好的运行。然而随着需求的不断添加，越来越多的人加入开发团队，代码库也在飞速的膨胀。慢慢的，单体应用变得越来越臃肿，可维护性差、灵活性逐渐降低，维护成本也越来越高。

单体应用架构存在的问题：

·     复杂性高：单体应用整个项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起，每次修改代码都会令人心惊胆战。

·     技术债务：随着时间推移、需求变更、人员迭代等，代码层面出现“不坏不修”，已使用的系统设计或代码难以被修改。

·     部署频率低：随着代码的增多，在单体应用中每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式耗时长、影响大、风险高，使得单体应用上线部署较为谨慎。

·     可靠性差：系统中的一个BUG可能会导致整个系统的奔溃。

·     扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行收缩。

·     阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。

三、微服务应用架构

微服务架构风格是分布式架构的一种很好的架构实现模式，它将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中。服务间通信采用轻量级通信机制。这些服务围绕业务能力构建，并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，也可以使用不同的数据存储技术。

微服务架构具备的应用特点：

1. 每个微服务单独运行在自己的容器里。

2. 多个微服务共同组建起整个应用系统。

3. 每个服务为独立的业务开发，一个微服务只关注某个特定的功能。

4. 微服务之间通过一些轻量级的通信机制进行通信。

5. 可以使用不同的开发语言和存储技术。

6. 可自动部署。

微服务架构面临的挑战：

1. 运维成本提高：在单体架构中，只需要保证一个应用的正常运行。在微服务架构中，更多的服务意味着更多的运维投入。

2. 分布式架构的复杂性：在分布式系统中，系统的容错性、网络延迟、分布式事务等都对技术提出了巨大挑战。

微服务架构设计原则：

1. 单一职责原则：单一职责是指一个单元（类、方法或服务）只关注整个系统功能中单独、有限的一部分。单一职责原则可以帮助我们更优雅的开发、更敏捷的交付。

2. 服务自治原则：服务自治是指每个微服务具备独立的业务能力、依赖与运行环境。

3. 轻量级通信机制：微服务之间应该通过轻量级的通信机制进行交互。

4. 微服务粒度：服务设计初期，应该使用合理的粒度划分微服务，而不是一味的把服务做小。代码量的多少不能作为微服务划分的依据，因为不同的微服务本身的业务复杂性不同，代码量也不同。

如今的招标采购业务系统发展的越来越成熟庞大，其功能范围广、业务流程长、用户数量庞大及系统对接复杂等多个特点，招标采购系统的技术架构不得不进行重构，将其传统的单体架构升级为当下最火热的分布式微服务应用架构。

---