多个微服务的接口依赖如何测试_一文看懂微服务

现在微服务大行其道，好像搞应用开发还不懂微服务，就落后别人一个时代了。那么什么是微服务？为什么是微服务？微服务应用的场景是什么？应该如何上手微服务？

软件开发的几种模式

在了解微服务之前，有必要先了解一下软件开发的组织历史，这样才能让我们更好的了解微服务。

瀑布式开发

软件工程的名词借鉴与建筑工程，软件开发的思想和套路，很长时间也来自建筑行业。在建筑行业，我们要盖一座大厦，先要搞清楚想要什么样子的大厦，然后找设计院设计好建筑图纸，然后剩下的就是交给工程队依据设计图纸进行施工，楼改好以后要让负责验收的验收队进行质检验收。那么对应的软件开发也就变成需求分析，先搞清我们要开发一个什么样的软件，然后软件设计，接下来交给码农做软件开发，最后交给测试人员进行质量测试。这样的分工貌似还不错，而且在很长一段时间确实取得了不菲成就。这样分工以后，突破了一个人开发软件的时代，让不同层次的人负责不同的业务，大家相互协调分工合作。而且有人专门负责设计，有人负责编码，有人负责测试。软件无论规模，稳定性和质量较个人时代都有了大规模的提升。

然而随着软件工程规模的越来越大，特别是互联网出现以后，不但软件规模大，而且变化还快，上午人们还在寻找一匹快马，晚上就已经变成了汽车。人们渐渐发现软件不像建筑一样很容易具象化，然后可以清楚的表达设计，而且还不容易变化，很少有一年前需要一个大裤衩的建筑，一年后希望给它改成鸟巢。但是在软件行业这样的需求变化简直是家常便饭。人们发现软件越来越难设计，变化太经常了。这个时候，一般的软件开发和需求方都要反复确认，每次确认要签字画押，保证不能修改需求。但是这么干明显不能适应市场。为了解决这些问题，人们也想和很多办法，比如面向对象编程，软件工程的原则，总结设计模式，都是为了来更好的应对变化。但是都不能很好的面对变化，软件人总结：没有银弹。

敏捷开发

这个时候有人提出来了：既然变化是不可避免的，不如我们先不要抱怨了，接受这种变化吧。既然软件不那么好设计架构。那么要不然，让我们先把架构的问题放一放。先把现在需要的最小的核心功能做出来。然后市场需要啥，咱们就在上面加什么，我们要拥抱变化嘛！但是这样一来，又出现很多问题，一直这样修修补补的代码，用不了多久就变成一团意大利面了，连他妈都不认识他是谁了，别说开发的人了。而且修修改改很容易触一发而动全身。上周递交的bug确实修改好了，但是上上周明明测试没有问题的代码，又出现大问题了。而且这个时候，如果每次修改都要对整个系统进行检查和测试，又太浪费人力物力，变化依然是噩梦。

为了解决这些问题。软件人又想到了很多办法。比如： 1. 面向测试开发。我们既然要拥抱变化，那么我们不如把需要实现的结果直接写成测试用例。然后再去写能满足测试用例的代码，这样让机器去自己跑一边，如果测试用例没问题，证明我们的代码至少没大的问题。而且如果不幸发生了触一发而动全身的问题。那么测试用例能帮我们及时的发现问题。 2. 依赖抽想而非依赖实现的面向接口编程。人们发现无论如何变化，总体的契约很少变化，那么我们定义好接口。所有的实现都依赖于接口，然后用各种设计模式来保证接口不变依然可以拥抱变化，这样的变化最少是万变不离其宗了，就有章法可寻。 3. 既然是面向接口编程，不依赖实现，那么我们就很少去new一个对象，而是通过反射或者容器技术去实现IOC。 4. 既然是拥抱变化开发，那么就意味着更新迭代特别快，我们仅仅保证开发和开发质量还不行，还想实现快速自动化的部署，这就是持续集成的概念。

即便是这些问题都解决，还是感觉少点什么！

每次开发都要下载所有的应用代码，然后开发完成后要测试所有的用例，然后再进行所有代码的编译。然后把程序停掉进行更新。能不能把不变得代码不进行修改，然后只修改更新变化的代码。能不能每次只编译变化的代码？而不动不变得代码？能不能进行热更新，不需要停服就可以完成更新。甚至能不能先让一部分客户测试下新的功能？

微服务时代

如果我们把每部分都做成一个独立的应用。然后哪块需要变化我们就把那一块进行开发，编译然后更新，只要保证每块和每块直接的契约（接口）不变化。那么几乎都可以做到我们上面的要求。这样把一个应用拆解厂多个应用的办法，我们就称之为微服务。这样我们就可以实现热更新，而且还不用动其他的代码，需要更新那个，我们就单独架设一个应用，然后让其他应用调用即可。同时还可以保存新旧两个版本，然后一部分客户走旧的接口，另外一部分走新的接口。而且还可以突破以前单台服务器的问题，我们可以把不同的应用部署在不同的服务器，甚至一个应用部署多个服务器，既可以减负，还可以保证高可用，想想就激动，太有才了！

先别急着激动。因为马上就会遇到一大堆的问题。 1. 单体应用相对来说调用简单，直接函数调用，出错的可能性小很多。现在分成一堆应用，每个应用直接相互调用。网路通信出问题的可能性更大。 2. 一个应用如果更新，那么是把以前的应用直接停掉进行更新呢？还是不停以前的，先开一个新的应用，那么调用他的应用怎么能知道呢？ 3. 这一大堆的应用，万一那个出问题了？要如何确认并且及时的修正呢？ 4. 以前单体应用，每次更新，更新1个应用，即便有多台服务器，数量相对较少。现在一下子几十个应用。以前更新都要熬夜通宵，到0点用户少了，进行更新。然后还要反复测试，现在更新这么多岂不是要搞死人。 5. 如果一个应用启动多个实例，那么调用者到底要调用哪一个，万一其中一个有问题了，调用者如何屏蔽掉这个去调用其他饿。 6. 相比之下微服务相互调用，效率肯定远远低于单体应用。说好的高并发变成了高负载。

那么既然有这么多问题，就得找到解决方法嘛。

docker 容器技术

这个时候出来一个神器，叫做docker.他可以把一个服务器虚拟化好多服务器，而且环境相同。更主要的是这个玩意效率高，比以前的虚拟机运行的成本低，消耗服务器资源少，这样才能在一个服务器中虚拟化成百上千的虚拟机而不会宕机。此外这个家伙的环境配置，安装程序，启动服务，都是用命令行就可以执行。你可以把这些命令行提前写好，结合CI工具，一个按钮，就可以自动完成从仓库拉去代码，然后配置好环境，并且按照需求或者要求，在服务器中启动若干个配置好的应用。docker的容器技术，为微服务奠定了基本的基础。

服务治理中心

这么多微服务A调用B，B又调用C，容器把他们一股脑地安装到了好多台服务器上，每个服务器的地址都不一样，而且端口也不一样，固定下来写调用关系吧，端口一发生改变，就崩塌了。这个时候很容易写到一个东西。就是大家把每个服务的地址和端口都登记到一个地方，然后再去这个地方查找具体的服务对应的地址和端口，然后再去调用，有点类似互联网的DNS服务器。这个东西就叫做服务器治理中心，Java中常用的Spring cloud 里面的Eureka，或者阿里的Nacos, Zookeeper。负责登记保存信息的叫做治理服务器，而每个应用都需要一个治理的客户端来把自己登记到服务器上。

客户端负载均衡器

我们提到了每个模块都会搭建很多应用，或者说每个应用都会有很多实例。怎么决定调用这个模块的时候，具体走哪个应用。而且我们去手写调用代码，总是感觉非常麻烦。这个时候就有了负载均衡器这个概念。一方面简化自己写网络请求处理的代码，另外可以根据不同的策略，把请求按期望的分布到不同的应用上去。这个就是负载均衡器的概念。如spring cloud中 Ribbon。

断路器

我们提到的问题中，会有某个特殊情况，其中的一个应用宕机了，那么传递给他请求都会出错。如果不能及时把这个应用给剔除掉，就会有若干请求总是出错。这个时候就用到了断路器。当满足一定的条件，我们就把一个应用给剔除掉，直接剔除掉，或者给出一个简单的提示。这个时候就叫做降级服务，比如你双十一去某宝购物，它服务器压力太大，在奔溃的边缘了，就会给你一个提示：当前用户访问太多，请稍后。另外如果可以限制某个接口流量，而不是到他崩溃了再剔除，岂不是更好，这个就是限速器。都集合在断路器中，如spring cloud中的Hystrix和resilience4j等等。

网关

我们的断路器和负载均衡都是给内部调用使用的。但是我们面向客户的应用，不可能要求每个客户都在自己浏览器上安装断路器或者负载均衡。我们需要一个东西挡在我们面向客户的接口和客户之间。以前我们做单体应用的时候，我们用硬件负载均衡或者nginx来实现。当然现在我们依然可以用ngix来实现，但是如果我们希望能够更加精确的编程比如某个接口进行限流，熔断以后如何降级服务。然后什么接口优先保证，什么接口次要。这个时候如果能编程就更好,nginx给人的感觉总是配置。所以我们经常用到spring cloud中的zuul或者gateway

配置服务

这么多应用，万一我们想修改个什么东西。比如修改下数据库密码，这下可算是捅了马蜂窝了。挨着一个一个修改，然后重启。如果能有几种在一个地方，我们只需要修改一处该多好了。这个时候就用到了spring cloud config.我们可以在本地文件，或者git仓库，或者数据库中修改，就可以几种管理所有的配置服务。是不是更加方便了呢？

全链路追踪

基本上经过我们上面的学习和了解，跑起来一组微服务一点问题都没有了。但是如果中间某个应用出问题了，咱们只能等待断路器给他断掉，然后等流量过去了，再自行恢复。能不能恢复，我们只能听天由命，因为我们也不一定知道哪个出问题，不知道问题在哪里，怎么解决。这个时候就需要一个追踪的东西，能知道一个访问调用了多少环节，每个环节占用多少时间，方便及时的发现问题，并且处理问题。同时还有助于我们尽早优化代码。这个玩意儿，我们叫做全链路追踪如spring cloud sleuth.

监控

有了链路追踪，我们的更容易发现问题。我们还需要需要一个监控器，让各种数据汇总成图标。spring cloud提供了一个spring cloud admin很方便容易的让我们对所有的微服务进行监控。

日志管理

我们做单体应用的时候，就少不了日志来发现问题。微服务那么多应用，更少不了日志。如果想以前一样的保存到一个文件，查找问题就是大海捞针，不用担心，前人已经给我们开发了十分完善的轮子。比如Elasticsearch和Kibana，方便我们可视化的对日志进行管理。

消息队列 数据流软件

在这么多服务相互调用，然后有的服务可能会一次调用多个其他服务。比如一个订单服务，收到订单以后，肯定得从买家账户扣钱，还得添加购物车，同时还得通知卖家库存减少等等操作。那么可能每个部分都是一个服务，这样相互调用耦合度就非常大。特别是，如果业务链条需要延长了，那么就需要去修改具体的服务。这个时候就引入了消息队列，和数据流的感念。负责订单的模块，只需要把相关的消息放到消息队列，然后其他需要接受到订单消息进行的操作，只需要订阅该队列，就可以依次执行。大大降低耦合，拥抱变化。

如果理解了微服务的由来的必要性，就很容易理解每一个部分为什么出现，是应对什么样的应用场景。学习起来就会事半功倍。