下载掌阅APP，畅读海量书库
立即打开
在讲解微服务架构中的常用技术之前，先来讲一个让笔者印象很深刻的问题。曾经有一个实习生问了这样一个问题：“如果一个系统调用了外部的各种接口，如短信服务接口、电子合同接口、支付接口、微信开放平台接口等，那么这种系统是不是微服务架构呢？”
为了便于理解，笔者画了一张架构简图，如图2-18所示。读者可以思考一下这种架构是不是微服务架构，以及是微服务架构与不是微服务架构的原因。
图2-18 项目 N 的架构简图
在项目 N 的代码里，为了完成相应功能的开发，调用了其他云服务提供商的各种接口，这些接口通常是基于HTTP/HTTPS协议的，开发人员需要根据云服务提供商给出的开放文档进行对接和功能开发。可以把云服务提供商所开放的各个接口当作服务提供方，而且服务间的通信也是正常的，与微服务架构类似，把它当作微服务架构可以吗？
答案是不可以。
首先，在回答这个问题前，需要对系统做一个边界的限定。项目 N 的边界在哪里？外部接口能不能被算到项目 N 中？其实，在实际开发时，对这些云服务提供商的各种接口通常只有调用权限，根本没有所有权。因此，系统边界就只能在项目 N 中，项目 N 不是微服务架构的项目，就是一个常见的单体应用。对项目进行边界划分后，答案就非常清晰了，系统边界的划分如图2-19所示。
图2-19 项目 N 与外部服务的系统边界划分
项目 N 里并没有微服务架构的相关特性、没有进行服务化拆分、没有基本的服务注册中心、没有用到任何市面上或自研的微服务框架，只是调用了一些云服务厂商提供的开放接口，所以它肯定不是微服务架构。
微服务架构中常用的技术栈如下：
（1）服务注册与服务发现；
（2）服务通信；
（3）负载均衡器；
（4）配置中心；
（5）服务网关；
（6）断路器；
（7）服务监控；
（8）链路追踪；
（9）消息队列。
根据具体的业务和项目，可能不会用到上述所有的技术及对应的技术栈，也可能用到其他技术和中间件，如自动化构建、自动化部署、分布式事务、全局锁等。这就需要开发团队和开发人员自行选择了。
本章首先介绍微服务架构的概念，然后顺着互联网项目架构演进的方向，介绍微服务的雏形及系统架构往微服务架构方向上演进的原因。接着讲到微服务架构解决了哪些痛点，以及微服务架构有哪些优点使它能够很好地适应IT行业的要求，使它成为近些年比较火热的话题和后端技术架构演进时都会考虑的一个架构方案。当然，本章也列举了微服务架构中的一些难点和不足之处，以及一些对微服务架构的思考，并最终通过一个项目 N 的案例来区分一个项目是否为微服务架构，同时介绍了微服务架构中的常见技术，希望各位读者能有所收获，并且对微服务架构有一个全面的认识。