第1章

认识微服务架构

学习目标

· 了解微服务和微服务架构的概念

· 熟悉微服务架构的优点与不足

· 了解微服务架构的技术选型

微服务（Microservice）概念的提出已经有很长一段时间了，但在最近几年才开始频繁地出现。虽然现在很多公司都开始采用微服务及其架构来满足实际需求，但这种方式并没有普及，很多开发人员还只停留在听说过“微服务”或“微服务架构”这些词上。那么为什么需要微服务架构？什么是微服务架构？又如何去构建微服务架构呢？本章将针对这些问题进行一一讲解。

1.1 为什么需要微服务架构

任何一个新事物或者新技术的出现，必然有其出现的原因，微服务架构也不例外。随着互联网技术的发展，传统的应用架构已满足不了实际需求，微服务架构就随之产生。那么传统应用架构到底出了什么问题呢？又如何解决？接下来的两个小节中，我们将从传统单体架构的问题开始，对为什么需要微服务架构进行详细讲解。

1.1.1 传统单体应用架构的问题

通常我们所使用的传统单体应用架构都是模块化的设计逻辑，程序在编写完成后会被打包并部署为一个具体的应用，而应用的格式则依赖于相应的应用语言和框架。例如，在网上商城系统中，Java Web工程通常会被打成WAR包部署在Web服务器上，而普通Java工程会以JAR包的形式包含在WAR包中，如图1-1所示。

图1-1 早期单体架构

图1-1中的这种应用开发风格很常见，它易于开发和调试，并且易于部署。在用户量不多时，此种架构方式完全可以满足需求，但随着用户人数的增加，一台机器已经满足不了系统的负载，此时我们就会考虑系统的水平扩展。通常情况下，我们只需要增加服务器的数量，并将打包好的应用拷贝到不同服务器（如Tomcat），然后通过负载均衡器（如Apache、Nginx）就可以轻松实现应用的水平扩展，如图1-2所示。

图1-2 传统单体应用架构

在早期，单体架构的这种扩展方式可以很好地满足使用需求，但随着时间的推移，这种方式就会产生很多问题，具体表现如下。

1. 应用复杂度增加，更新、维护困难

一个简单的应用会随着时间的推移而逐渐变大。一旦应用变得庞大而又复杂，开发团队将会面临很多问题，其中最主要的问题就是这个应用太复杂，以至于任何单个开发者都很难进行二次开发或维护。

2. 易造成系统资源浪费

虽然使用负载均衡的方式可以对项目中的服务容量进行水平扩展，但由于传统单体架构的代码中只有一个包含所有功能的WAR包，所以在对服务容量扩容时，只能选择重复地部署这个WAR包来扩展服务能力，而不仅仅是扩展了所需的服务。这样就会导致其他不需要扩展的服务也进行了相应的扩展，但这些扩展是不需要的，因此这种方式会极大地浪费资源。

3. 影响开发效率

当一个应用越大时，启动时间就会越长。开发和调试的过程中，如果有很大一部分时间都要在等待中度过，那么必然会对开发效率有极大的影响。

4. 应用可靠性低

传统单体应用架构在运行时的可靠性比较低，当所有模块都运行在一个进程中时，如果任何一个模块中出现了一个Bug，可能会导致整个进程崩溃，从而影响到整个应用。

5. 不利于技术的更新

传统单体应用架构一旦选定使用某些技术，则后期的开发和扩展将在这些技术的基础上实现。如果需要更改某种技术，则可能需要将整个应用全部重新开发，这种成本是非常大的。

当然，传统单体应用架构的问题还不只这些，但出现这些问题的根本原因可以说就是由于传统单体架构中一个WAR包内包含了系统的所有服务功能所导致的。随着业务变得越来越多，问题也就越来越多。

1.1.2 如何解决传统应用架构的问题

针对传统单体架构的问题，大部分企业通过SOA（Service-Oriented Architecture，面向服务的架构）来解决上述问题。SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去，因此基于SOA架构的应用可以理解为一批服务的组合。