第1章微服务架构介绍

近年来，微服务架构一直是互联网技术圈的热点之一，越来越多的互联网应用都采用了微服务架构作为系统构建的基础，很多新技术和理念如Docker、Kubernetes、DevOps、持续交付、Service Mesh等也都在关注、支持和跟随微服务架构的发展。

本章将会概要性地介绍微服务架构：包括微服务架构是如何演进的，微服务架构的主要流派，当前主流的云原生应用与微服务之间的关系等。

1.1　微服务架构的出现

从单体应用架构发展到SOA架构，再到微服务架构，应用架构经历了多年的不断演进。微服务架构不是凭空产生的，而是技术发展的必然结果，分布式云平台的应用环境使得微服务代替单体应用成为互联网大型系统的架构选择。目前，虽然微服务架构还没有公认的技术标准和规范草案，但业界已经有了一些很有影响力的开源微服务架构解决方案，在进行微服务化开发或改造时可以进行相应的参考。

1.1.1　单体应用架构

与微服务架构对比的是传统的单体应用。Web应用程序发展的早期，大部分Web工程是将所有的功能模块打包到一起部署和运行，例如Java应用程序打包为一个war包，其他语言（Ruby、Python或者C++）编写的应用程序也有类似的做法。单体应用的实现架构类似于图1-1中的电影售票系统。

这个电影售票系统采用分层架构，按照调用顺序，从上到下为表示层、业务层、数据访问（DAO）层、DB层。表示层负责用户体验；业务层负责业务逻辑，包括电影、订单和用户三个模块；数据访问层负责DB层的数据存取，实现增删改查的功能。业务层定义了应用的业务逻辑，是整个应用的核心。在单体应用中，所有这些模块都集成在一起，这样的系统架构就叫做单体应用架构，或称为巨石型应用架构。单体应用是最早的应用形态，开发和部署都很简单。在中小型项目中使用单体应用架构，能体现出其优势，且单体应用的整体性能主要依赖于硬件资源和逻辑代码实现，应用架构自身不需要特别关注。

单体应用的集成非常简洁，IDE集成开发环境（如Eclipse）和其他工具都擅长开发一个简单应用；单体应用易于调试，由于一个应用包含所有功能，所以只需要简单运行此应用即可进行开发测试；单体应用易于部署，只需要把应用打包，拷贝到服务器端即可；通过负载均衡器，运行多个服务实例，单体应用可以轻松实现应用扩展。

但是，随着应用项目变得复杂、开发团队不断扩张之后，单体应用的不足和弊端将会变得很明显，主要有如下不足：

可靠性：每个bug都可能会影响到整个应用的可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，都可能拖垮整个进程。

复杂性高：单体应用巨大的代码库可能会令人望而生畏，特别是对团队新成员来说。应用难以理解和迭代，进而导致开发速度减慢。由于没有清晰的模块边界，模块化会逐渐消失。

持续部署困难：巨大的单体应用本身就是频繁部署的一大障碍。为了更新一个组件，必须重新部署整个应用。这会中断那些可能与更改无关的后台任务（例如Java应用中的Quartz任务），同时可能引发其他问题。另外，未被更新的组件有可能无法正常启动。重新部署会增加风险，进而阻碍频繁更新。

扩展能力受限：单体架构只能进行一维扩展。一方面，它可以通过运行多个应用服务实例来增加业务容量，实现扩展。但另一方面，不同的应用组件有不同的资源需求：有的是CPU密集型的，有的是内存密集型的。单体架构无法单独扩展每个组件。

阻碍技术创新：单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。单体架构迫使团队长期使用在开发初期选定的技术栈，比如选择了JVM的语言，此时以非JVM语言编写的组件就无法在该单体架构的应用中使用。