Spring Cloud与微服务构建学习笔记之微服务简介（一）

随着互联网技术的发展，业务场景越来越复杂，传统的单体架构已经很难满足互联网技术的发展要求，主要体现在已下两个方面：
（1）随着业务复杂度的增加，代码的可维护性、可扩展性、和可读性降低。
（2）维护系统的成本提高，修改系统的成本也在提高。
因此，为了满足越来越复杂的业务需求，出现了微服务的概念。
什么是微服务？
微服务是用来描述将软件应用程序设计为独立部署的服务的一直特殊方式。微服务架构的系统是一个分布式系统，按业务领域划分为独立的服务单元，有自动化运维、容错、快速演进的特点，它能够解决传统单体架构的痛点（即随着业务复杂度的增加其代码的可维护性、可扩展性、可读性降低，以及系统的维护成本和修改成本增加等），同时也能满足越来越复杂的业务需求。
1.1 单体架构简介
软件设计中经常使用三层模型：表示层、业务逻辑层、和数据访问层。
①表示层：用于直接和用户交互、也称为交互层，通常是网页、UI等。
②业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后才能展示给用户。
③数据访问层：用于操作数据库。
一个典型的单体应用就是将所有的业务场景的表示层、业务逻辑层、和数据访问层放在一个工程中，最终经过编译、打包部署至服务器。
1.2 单体架构存在的不足：
在应用初始阶段，单体架构的开发速度以及运维难度拥有很大的优势，但是随着业务复杂度的增加，单体架构存在以下不足：
①代码量越来越大，可读性，可维护性，和可扩展性降低。
②随着用户的增加，程序承受的并发量增加，而单体应用的并发量有限。
③测试难度增加，修改某个业务可能会影响其他业务，因此测试范围较大，难度较大。
虽然可以通过集群部署、并增加负载均衡服务器（例如nginx）、增加集群部署的缓存服务器、文件服务器、将数据库读写分离以应对高并发的访问量，但随着业务量、业务复杂度、以及使用的用户（海量的用户时、数据库也会成为瓶颈）、场景越来越复杂时，单体架构依然存在上面描述的不足。
1.3 微服务介绍
微服务就是将单一的程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是HTTP RESTFUL API。这些服务是按照不同的业务进行划分构建，并通过完全自动化部署机制部署，这些微服务可以使用不同的编程语言，以及不同的数据存储技术，以保证最低限度的集中式管理。
因此总结微服务的特点如下：
①微服务是按照业务划分的一个独立运行的程序，即服务单元。
②服务与服务之间通过HTTP协议相互通信。
③自动化部署。
④可以使用不同的编程语言。
⑤可以使用不同的存储技术（数据库）。
⑥服务可以集中化管理。
⑦微服务是一个分布式系统。
以下是对微服务七大特点的简要介绍：
（1）服务单元（微服务按照业务进行划分）
微服务的“微 ”是按照业务进行划分，一个大的业务可以拆分成若干个小的业务，一个小的业务也可以拆分成若干个更小的业务，具体的业务如何拆分由研发人员决定。例如微博最常见的功能是微博内容，关注和粉丝，而其中微博内容又分为正文，点赞、评论、转发、回复等等。具体这些业务如何划分需在开发过程中具体定义。
按业务划分后的微服务单元都是独立部署的，运行在独立的进程中，这些单元也都是高度组件化，并提供了稳定的模块边界，服务与服务之间没有任何的耦合，有非常好的扩展性和复用性。
（2）微服务之间通过HTTP进行通信
微服务单元独立部署，运行在各自的进行中，因此服务之间的通知一般倾向于HTTP这种简单的通信机制，更多的时候使用RESTFUL API,这种接受请求，处理业务逻辑，返回数据的HTTP模式非常高效，并且该通信机制与平台语言无关，例如可以使用JAVA语言写的服务消费GO语言写的服务，用GO语言写的服务也可以消费RUBY语言写的服务，不同的服务可以采用不同的语言实现，不同的平台部署，他们之间使用HTTP进行通信。
服务与服务之间还可以通过消费总线进行通信，例如RabbitMQ、Kafaka。通过发送消息和订阅消息进行通信。
服务与服务之间通信的数据格式一般为JSON、XML，JSON格式数据比XML更轻量，还可以用Protobuf进行数据序列化，经过序列化的数据为二进制数据，比JSON数据更轻量，但是可读性很差，需要反序列化，但是由于Protobuf序列化的数据很轻量，因此Protobuf在通信协议和数据存储上很受欢迎。
上述通信机制也存在一定的弊端，即通信机制不可靠，会有失败的情况。

（3）微服务的数据库独立
在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库的表的数量越来越多，难以管理和维护，并且数据量的增加会导致查询速度越来越慢。

微服务的服务与服务之间无耦合，而数据库也可以是独立的。一个典型的微服务架构就是每个微服务都有自己独立的数据库，数据库之间没有任何联系。
数据库独立的好处是：（1）随着业务的不断扩张，服务与服务不需要提供数据库集成，而只需要提供API接口相互调用；（2）单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。
数据库的存储方式除了关系型数据库，非关系数据库的应用也非常广泛，例如MongDB、Redis，它们有着良好的读写性能。一个典型的微服务的系统，可能每一个服务的数据库都不相同，每个服务所使用的数据存储技术可根据业务需求来选择。例如日志可以选择使用ES。

（4）.微服务的自动化部署
在微服务架构中，一个系统会被拆分为若干个微服务，而有多少个微服务就需要部署多少次，随着服务数量的增加，微服务的数量就会越来越多，而部署难度也会成倍增加，这时需要更稳定的部署机制。随着技术的发展，尤其是Docker容器技术的推进，以及自动化部署工具（例如开源组件Jenkins）的出现，自动化部署变得越来越简单。

自动化部署可以提高部署的效率，减少人为的控制，部署过程中出现错误的概率降低，随着DevOps这种全新概念的推进，自动化部署必然会成为微服务部署的一种方式。

（5）.服务集中化管理

微服务系统是按业务单元来划分服务的，服务数量越多，管理起来就越复杂，因此微服务必须使用集中化管理。目前 流行的微服务框架中，例如Spring Cloud采用Eureka来注册服务和发现服务，另外，Zookeeper、Consul等都是非常优秀的服务集中化管理框架。

（6）.分布式架构

分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。分布式系统的复杂任务通过计算机之间的相互协作来完成，当然简单的任务也可以在一台计算机上完成。分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务器可以部署不同的机房和不同的地区。

微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务、分局锁、全局ID等，而单体系统不需要考虑这些复杂性。
另外，分布式系统的应用都是集群化部署，会给数据一致性带来困难。分布式系统中的服务通信依赖于网络，网络不好，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互关系依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会汪消耗殆尽，最终使得该服务不可用，由于服务的相互依赖，可能会导致整个系统的不可用，这就是“雪崩效应”。为了防止些类事件的发生，分布式系统必然要采取相应的措施，例如“熔断机制”。

（7）.熔断机制

为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。在用Spring Cloud构建的微服务系统中，采用了熔断器（即Hystrix组件的Circuit Breaker）去做熔断。

例如在微服务系统中，有a b c d e f g h等多个服务，用户的请求通过网关后，再到具体的服务，服务之间相互依赖，例如服务b依赖于服务f，一个对外暴露的API接口需要服务b和服务f相互协作才能完成。如果此时服务b出现故障或者网络延迟，在高并发的情况下，服务b会出现大量的线程阻塞，有可能在很短的时间内线程资源就被消耗完了，导致b的不可用。如果服务b为较底层的服务，会影响到其它服务，导致其它服务会一直等待服务b的处理。如果服务b迟迟不处理，大量的网络请求不仅仅堆积在服务b，而且会堆积到依赖于服务b的其它服务，从而由b开始，影响到整个系统，导致整个系统的不可用。这是一件非常可怕的事，因为服务器运营商的不可靠，必然会导致服务的不可靠，而网络服务商的不可靠性，也会导致服务的不可靠。在高并发的场景下，稍微有点不可靠，由于故障的传播性，会导致大量的服务不可用，甚至导致整个系统崩溃。

为了解决这一难题，微服务架构引入了熔断机制。当服务b出现故障，请求失败次数超过设定的阀值之后，服务b就会开启熔断器，之后服务b不进行任何的业务逻辑操作，执行快速失败，直接返回请求失败的信息。期货依赖于b的服务就不会因为得不到响应而线程阻塞，这时除服务b和依赖于服务b的部分功能不可用外，其它功能正常。

熔断器还有另外一个机制，即自我修复的机制。当服务b熔断后，经过一段时间，半打开熔断器。半打开的熔断器会检查一部分请求是否正常，其它请求执行速度失败，检查的请求如果响应成功，则可以判定服务b正常了，就会关闭服务b的熔断器；如果服务b还不正常，则继续打开熔断器。
熔断组件同时会提供一系列的监控，例如服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等。