1.2.1 什么是微服务
“微服务”最初是由Martin Fowler在2014年写的一篇文章《MicroServices》中提出来的。关于Martin Fowler的介绍，维基百科上有如下的描述。
Martin Fowler，软件工程师，也是一个软件开发方面的著作者和国际知名演说家，专注于面向对象分析与设计、统一建模语言、领域建模，以及敏捷软件开发方法，包括极限编程。主要著作有《可重用对象模型》《重构——改善既有代码的设计》《企业应用架构模式》《规划极限编程》等。
对于微服务，业界没有一个严格统一的定义，但是作为“微服务”这一名词的发明人，Martin Fowler对微服务的定义似乎更具有权威性和指导意义，他的理解如下。
简而言之，微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP RESTFUL API。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署。这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。
以我个人对这段话的理解，总结微服务具有如下特点。
•按业务划分为一个独立运行的程序，即服务单元。
•服务之间通过HTTP协议相互通信。
•自动化部署。
•可以用不同的编程语言。
•可以用不同的存储技术。
•服务集中化管理。
•微服务是一个分布式系统。
根据这些特点，下面来进一步阐述微服务。
1．微服务单元按业务来划分
微服务的“微”到底需要定义到什么样的程度，这是一个非常难以界定的概念，可以从以下3个方面来界定：一是根据代码量来定义，根据代码的多少来判断程序的大小；二是根据开发时间的长短来判断；三是根据业务的大小来划分。
根据Martin Fowler的定义，微服务的“微”是按照业务来划分的。一个大的业务可以拆分成若干小的业务，一个小的业务又可以拆分成若干更小的业务，业务到底怎么拆分才算合适，这需要开发人员自己去决定。例如微博最常见的功能是微博内容、关注和粉丝，而其中微博内容又有点赞、评论等，如何将微博这个复杂的程序划分为单个的服务，需要由开发团队去决定。
按业务划分的微服务单元独立部署，运行在独立的进程中。这些微服务单元是高度组件化的模块，并提供了稳定的模块边界，服务与服务之间没有任何的耦合，有非常好的扩展性和复用性。
传统的软件开发模式通常由UI团队、服务端团队、数据库和运维团队构成，相应地将软件按照职能划分为UI、服务端、数据库和运维等模块。通常这些开发人员各司其职，很少有人跨职能去工作。如果按照业务来划分服务，每个服务都需要独立的UI、服务端、数据库和运维。也就是说，一个小的业务的微服务需要动用一个团队的人去协作，这显然增加了团队与团队之间交流协作的成本。所以产生了跨职能团队，这个团队负责一个服务的所有工作，包括UI、服务端和数据库。当这个团队只有1～2个人的时候，就对开发人员提出了更高的要求。
2．微服务通过HTTP来互相通信
按照业务划分的微服务单元独立部署，并运行在各自的进程中。微服务单元之间的通信方式一般倾向于使用HTTP这种简单的通信机制，更多的时候是使用RESTful API的。这种接受请求、处理业务逻辑、返回数据的HTTP模式非常高效，并且这种通信机制与平台和语言无关。例如用Java写的服务可以消费用Go语言写的服务，用Go写的服务又可以消费用Ruby写的服务。不同的服务采用不同的语言去实现，不同的平台去部署，它们之间使用HTTP进行通信，如图1-4所示。
▲图1-4 不同语言、不同的平台的微服务相互调用
服务与服务之间也可以通过轻量级的消息总线来通信，例如RabbitMQ和Kaf ka等。通过发送消息或者订阅消息来达到服务与服务之间通信的目的。
服务与服务通信的数据格式，一般为JSON、XML，这两种数据格式与语言、平台、通信协议无关。一般来说，JSON格式的数据比XML轻量，并且可读性也比XML要好。另外一种就是用Protobuf进行数据序列化，经过序列化的数据为二进制数据，它比JSON更轻量。用Protobuf序列化的数据为二进制数据，可读性非常差，需要反序列化才能够读懂。由于用Protobuf序列化的数据更为轻量，所以Protobuf在通信协议和数据存储上十分受欢迎。
服务与服务之间通过HTTP或者消息总线的方式进行通信，这种方式存在弊端，其通信机制是不可靠的，虽然成功率很高，但还是会有失败的时候。
3．微服务的数据库独立
在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库的表的数量越来越多，难以管理和维护，并且数据量的增加会导致查询速度越来越慢。例如，一个应用有这样几个业务：用户的信息、用户的账户、用户的购物车、数据报表服务等。典型的单体架构如图1-5所示。
▲图1-5 单体服务共享一个数据库
微服务的一个特点就是按业务划分服务，服务与服务之间无耦合，就连数据库也是独立的。一个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。这样做的好处在于，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供API接口相互调用；还有一个好处是数据库独立，单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。
另外，随着存储技术的发展，数据库的存储方式不再仅仅是关系型数据库，非关系数据库的应用也非常广泛，例如MongDB、Redis，它们有着良好的读写性能，因此越来越受欢迎。一个典型的微服务的系统，可能每一个服务的数据库都不相同，每个服务所使用的数据存储技术需要根据业务需求来选择，如图1-6所示。
▲图1-6 微服务的数据库独立
4．微服务的自动化部署
在微服务架构中，系统会被拆分为若干个微服务，每个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次。随着服务数量的增加，如果微服务按照单体架构的部署方式，部署的难度会呈指数增加。业务的粒度划分得越细，微服务的数量就越多，这时需要更稳定的部署机制。随着技术的发展，尤其是Docker容器技术的推进、Kubernetes容器编排技术的发展，以及自动化部署工具（例如开源组件Jenkins）的出现，自动化部署变得越来越简单。
自动化部署可以提高部署的效率，减少人为的控制，部署过程中出现错误的概率降低，部署过程的每一步自动化，提高软件的质量。构建一个自动化部署的系统，虽然在前期需要开发人员或者运维人员的学习，但是对于整个软件系统来说是一个全新的概念。在软件系统的整个生命周期之中，每一步是由程序控制的，而不是人为控制，软件的质量提高到了一个新的高度。随着DevOps这种全新概念的推进，自动化部署必然会成为微服务部署的一种方式。
5．服务集中化管理
微服务系统是按业务单元来划分服务的，服务数量越多，管理起来就越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如Spring Cloud支持使用Eureka、Zookeeper和Consul来注册服务和发现服务，另外，Etcd和Nacos等都是非常优秀的服务注册与发现组件。
6．分布式架构
分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。当分布式系统对外提供服务时，用户是毫不知情的，还以为是一台服务器在提供服务。
分布式系统的复杂任务通过计算机之间的相互协作来完成，当然简单的任务也可以在一台计算机上完成。
分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务器可以部署不同的机房和不同的地区。
微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务、全局锁、全局Id等，而单体系统不需要考虑这些复杂性。
另外，分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通信依赖于网络，网络不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止此类事件的发生，分布式系统必然要采取相应的措施，例如“熔断机制”。
7．熔断机制
为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。在用Spring Cloud构建的微服务系统中，采用了熔断器（即Hystrix组件的Circuit Breaker）去做熔断。
例如在微服务系统中，有a、b、c、d、e、f、g、h等多个服务，用户的请求通过网关后，再到具体的服务，服务之间相互依赖，例如服务b依赖于服务f，一个对外暴露的API接口需要服务b和服务f相互协作才能完成。服务之间相互依赖的架构图如图1-7所示。
▲图1-7 服务之间相互依赖
如果此时服务b出现故障或者网络延迟，在高并发的情况下，服务b会出现大量的线程阻塞，有可能在很短的时间内线程资源就被消耗完了，导致服务b的不可用。如果服务b为较底层的服务，会影响到其他服务，导致其他服务会一直等待服务b的处理。如果服务b迟迟不处理，大量的网络请求不仅仅堆积在服务b，而且会堆积到依赖于服务b的其他服务。而因服务b出现故障影响的服务，也会影响到依赖于因服务b出现故障影响的服务的其他服务，从而由服务b开始，影响到整个系统，导致整个系统的不可用。这是一件非常可怕的事，因为服务器运营商的不可靠，必然会导致服务的不可靠，而网络服务商的不可靠性，也会导致服务的不可靠。在高并发的场景下，稍微有点不可靠，由于故障的传播性，会导致大量的服务不可用，甚至导致整个系统崩溃。
为了解决这一难题，微服务架构引入了熔断机制。当服务b出现故障，请求失败次数超过设定的阀值之后，服务b就会开启熔断器，之后服务b不进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。其他依赖于b的服务就不会因为得不到响应而线程阻塞，这时除了服务b和依赖于服务b的部分功能不可用外，其他功能正常。熔断服务b如图1-8所示。
▲图1-8 将服务b熔断
熔断器还有另一个机制，即自我修复的机制。当服务b熔断后，经过一段时间，半打开熔断器。半打开的熔断器会检查一部分请求是否正常，其他请求执行快速失败，检查的请求如果响应成功，则可以判定服务b正常了，就会关闭服务b的熔断器；如果服务b还不正常，则继续打开熔断器。这种自我熔断机制和自我修复机制在微服务架构中有着重要的意义，一方面，它使程序更加健壮；另一方面，为开发和运维减少很多不必要的工作。
最后，熔断组件往往会提供一系列的监控，例如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等，从而很容易让开发人员和运维人员实时地了解服务的状况。