[TOC]

小插曲

作为测试人员，我们需要了解后端的技术栈和架构设计，才能更好地精准狠测试，提高业务测试效率，给我们的业务测试注入一针强心针！记得只需要了解即可，不需要熟悉！下面我们来浅谈一下微服务···

单体应用概念

• 一个系统对应一个归档包 (war)，这个 war 包 包含了该工程的所有功能。我们称这种应用为单体应用，也就是我们常说的单体应用。 具体描述: 就是在我们的一个 war 包中，聚集了各种功能以及资源，比如 JSP JS,CSS 等。而业务中包含了我们的用户模块、订单模块支付模块、商品模块等。

优点

1. 架构简单单一，清晰明了，没有花里胡哨
2. 开发、测试很容易进行部署，直接将 war 包丢在 Tomcat 里

缺点

1. 随着业务扩展，代码越来越复杂，代码质量参差不齐，会让你每次提交代码 ，修改每一个小 bug 都是心惊胆战的。屎山的由来
2. 部署慢（依稀记得那时候运维小哥发布，所有人都在等着，都能打上一盘王者）
3. 扩展成本高，譬如用户模块是个 CPU 密集模块（涉及到运算，用户画像等）需要更加牛逼 CPU，而订单模块是个 IO 密集模块（涉及读写硬盘，存储订单数据）需要更加牛逼内存和硬盘；而我们无法针对单个功能模块进行扩展，一加就得加 CPU、内存和硬盘···
4. 重构系统难以进行···这么多的模块耦合在一起，一堆屎山无从下手

单体应用扩展

用户起来了，单机器部署的单体应用肯定是不满足业务的需求，老板说，没事那就加机器吧，每台机器配置都是 16c 32g，属实有点浪费···

微服务概念

• Microservice简称微服务，微服务架构模式就是将整个 web 应用组织成一系列小的 web 服务，而这些小服务能够独立编译和部署，并通过各自暴露的 API 接口相互通讯。它们彼此相互协作，作为一个大整体为用户提供功能，这些小服务又可以独立进行扩展
• 微服务其实就是服务化思路的一种最佳实践方向，遵循 SOA（面向服务的架构）的思路，各个企业在服务化治理的道路上走的时间长了，踩的坑多了，整个软件交付链路上各个环节的基础设施逐渐成熟了，微服务自然而然就诞生了。

下面举个通俗点的例子

刚出来工作的时候，那时候微服务还没兴起，服务实现和实施思路（相当于整个系统）是将很多功能从开发到交付都打包成一个很大的服务单元（一般称为 Monolith，单体应用），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。如下面的图片所示···一个茶壶煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子，可以在各个茶壶里定制不同口味，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元。

微服务核心

就拿上面的单体应用来说，根据业务把单体应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个小服务就是微服务，比如上面的商城系统，可以拆分成mh-pdm、mh-crm、mh-pay、mh-oms拆分了之后，即使mh-pay突然宕机了，只是支付功能不能用罢了，整个系统的核心功能还是可以用的，假如还是上面的单体应用，整个系统相当于瘫痪了···

优点

1. 易于开发和维护，由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护
2. 启动较快，这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。
3. 局部修改容易部署，譬如mh-oms出现了问题，只需修复mh-oms即可，修复之后部署即可生效，不必重启整个项目从而大大节约时间。
4. 技术栈不受限，譬如mh-oms使用 Java 写的，mh-pdm可以用 php 技术，技术更换成本很低。
5. 按需伸缩，譬如 xxx 中秋活动，流量比较大，部署mh-oms的服务器可以升级闪存和硬盘，提升性能，不必考虑其他模块的情况

缺点

1. 运维要求较高，对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的
2. 分布式的复杂性，对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来，什么上云,k8s,集群,容器调度一大堆
3. 接口调整成本高，譬如mh-oms要改创建订单的接口，创建订单接口被其他微服务所调用，所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高上游改东西了，可能影响到下游，下下下游···
4. 重复劳动，对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复==>这就有了组件组的诞生

微服务扩展

中秋活动到来，流量增多，用户量激增，可能会对订单服务影响比较大，对应加大部署订单服务的服务器性能

微服务架构

微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把一个一个的微服务组合管理起来，对外提供一套完整的服务

微服务适用场景

• 合适

  • 大型复杂项目
  • 快速迭代项目
  • 并发高项目

• 不合适

  • 业务稳定，业务不会经常改动
  • 迭代周期长，发版频率较低

未完待续

下次我们来讲讲微服务之间是如何通信的，还有相关的测试方法···