微服务架构有哪些特点海量资源.pdfVIP

本文由简悦SimpRead转码，原文地址

作为测试从业者，想要做好微服务的，就需要对它产生的由来和特点有一个充分的认识，带着

问题去理解它的特性，这样学习的思路就会很清晰。正所谓，知己知彼，百战百胜。希望通过本的

内容，能够让你理解微服务架构，为保障微服务的质量打下一定的理论基础。

首先，我以我自身的两份工作经历，来让你感受下什么是微服务，以及微服务架构的优缺点。这样有利

于你理解后面的内容，同时更加有代入感。

单体应用架构下的服务特性

我第一份工作是的测试保障工作，在功能测试之外做了很多服务端相关的工作，如编译后分

发、配置、部署、发布等。那时候的服务端应用程序是几个独立的几十兆、上百兆的文件。每个文件是

一个可执行文件，包含一个系统的所有功能，这些功能被打包成的文件，几乎没有外部依赖，可

以独立部署在装有Linux系统的硬件服务器上。这种应用程序通常被称为单体应用，单体应用的架构

方法论，就是单体应用架构（MonolithicArchitecture）。单体应用架构下，一个服务中包含了与用户

交互的部分、业务逻辑处理层和数据层。如果存在数据库交互则与数据库直连，如下图所示。

单体应用架构下，一个服务中，两个业务模块作为该服务的一部分存在同一进程中，它们通过方法调用

的方式进行通信，如下图所示。

通过在单体应用架构下，不同阶段的服务端相关工作，可以感知到单体应用的特性。

编译：完整编译一次需要30到60分钟不等，所以一般会限制编译时间，如晚上和午休各一次；

分发：编译完成后，在内网分发给不同的团队，一般是研发和测试人员；

部署：内网部署较简单，先将服务端文件到服务器本地，关闭运行中的服务器程序，将新

服务器文件覆盖至运行，再启动服务器程序即可。

2.对外发布阶段

服务器上进行发布时的操作与内网类似，但每一步会比内网更加严格。受制于公网速度和线上运行

的服务器个数，更新服务器需要几个小时，且更新期间服务不可用，因此每次发布需要花费研发和

测试团队的大量时间。为了确保应用程序不会由于新发布的功能而中断服务，研发团队和运营团队会达

成共识，极大减少更新的频次，比如两周左右停服更新一次，除非有特别严重的Bug需要修复。

3.线上运维阶段

因为所有的功能集中在少数的几个服务端文件中，一个Bug可能导致某个服务端文件产生，进而

影响服务的使用。上运维过程中如果出现性能瓶颈，也不能单独对热点模块进行扩容，只好针对该

热点模块所在的服务端文件进行整体的扩容。

4.其他阶段

服务端的技术栈是在立项时的技术调研阶段，经过慎重评估后选定的。它是一种平衡的技术栈，可以很

好地满足所有需求，因此每个团队成员都必须使用相同的开发语言、持久化及消息系统。

另外，随着时间的推移、需求的变更和技术人员的更替，服务应用中会形成许多技术。因为我完整

经历了那个项目，期间经历了多次大规模的“重构”，每次重构对整个项目的人员来说都是“”，但又

不得不进行。由于只有几个单独的可执行文件，所以项目文件包含了太多模块，这也使得整个项目非常

复杂，每次修改代码就需要非常，因为太容易引入新的Bug了。

现在应用程序日益复杂化，项目对于迭代速度的要求也越来越高，上述的不足会得更加明显，在这

种时代背景下，微服务架构开始在企业生根发芽。

微服务架构下的服务特性

后来我转到了互联网公司工作，所在项目的服务架构与过去经历过的单体应用架构下的服务差异巨大。

同等规模的研发团队，服务的个数竟然有近百个，虽然数量众多，但每个服务都只负责一小块儿具体的

业务功能，能独立地部署到环境中，服务间边界相对清晰，相互间通过轻量级的接口调用或消息队列进

行通信，为用户提供最终价值。这样的服务称为微服务（Microservice）。从本质上来说，微服务是

一种架构模式，是