1.微服务

1.1.简介

微服务(不是一个框架，而是一种架构思想)，它是用来描述将软件应用程序设计为独立部署的服务的种特殊方式。

微服务架构的系统是个分布式系统，按业务领域划分为独立的服务单元，有自动化运维、容错、快速演进的特点，它能够解决传统单体架构系统的痛点，同时也能满足越来越复杂的业务需求。

1.2.单体架构

1.2.1.优点

在应用的初始阶段，单体架构无论是在开发速度、运维难度上，还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段，用单体架构是非常明智的选择。

1.2.2.缺点

随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足，主要体现在以下 3 个方面：

1. 业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降，新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。

2. 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。

3. 测试的难度越来越大，单体应用的业务都在同个程序中，随着业务的扩张、复杂度的增加，单体应用修改业务或者增加业务或许会给其他业务带来定的影响，导致测试难度增加。

1.3.特点

微服务架构的风格，就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级通信机制，通常是 HTTP RESTFUL API 。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。

1.按业务(功能)划分为一个独立运行的程序，即服务单元。

  • 根据MartinFowler的定义，微服务的“微”是按照业务来划分的 。一个大的业务可以拆分成若干小的业务，个小的业务又可以拆分成若干更小的业务。
  • 按业务划分的微服务单元独立部署，运行在独立的进程中 这些微服务单元是高度组件化的模块，并提供了稳定的模块边界，服务与服务之间没有任何的相合，有非常好的扩展性和复用性。

2.服务之间通过HTTP协议相互通信。

3.可以用不同的编程语言。

  • 微服务单元之间的通信倾向于使用HTTP这种简单的通信机制。这种接受请求、处理业务逻辑、返回数据的HTTP模式非常高效，并且这种通机制与平台和语言无关。例如用Java写的服务可以消费用Go语言写的服务

4.自动化部署。

  • 在微服务架构中，系统会被拆分为若干个微服务，每个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次。
  • 随着服务数量的增加，如果微服务按照单体架构的部署方式，部署的难度会呈指数增加。业务的粒度划分得越细，微服务的数量就越多，这时需要更稳定的部署机制。随着技术的发展，尤其是Docker容器技术的推进，以及自动化部署工具（例如开源组件 Jenkins）的出现，自动化部署变得越来越简单。
  • 自动化部署可以提高部署的效率，减少人为的控制，部署过程中出现错误的概率降低，部署过程的每一步自动化，提高软件的质量。

5.可以用不同的存储技术。

6..微服务的数据库独立

  • 在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库的表的数量越来越多，难以管理和维护，并且数据量的增加会导致查询速度越来越慢。
  • 典型的单体架构如微服务的一个特点就是按业务划分服务，服务与服务之间无稠合，就连数据库也是独立的个典型的微服务的架构就是每个微服务都有自己独立的数据库，数据库之间没有何联系。
  • 这样做的好处在于，随着业务的不断扩张，服务与服务不需要提供数据库集成，而是提供API接口相互调用。
  • 数据库独立，单业务的数据盆少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。
  • 并且还可以使用其他不同类型的数据库。

7.服务集中化管理。

  • 目前流行的微服务框架中，例如SpringCloud采用Eureka来注册服务和发现服务。

8.微服务是一个分布式系统。

1.4.分布式系统

1.4.1.特点

1.分布式系统是集群部署的，由很多计算机相互协作共同构成，它能够处理海量的用户请求。

2.分布式系统通过网络协议来通信，所以分布式系统在空间上没有任何限制，即分布式服务器可以部署不同的机房和不同的地区。

3.微服务架构是分布式架构，分布式系统比单体系统更加复杂，主要体现在服务的独立性和服务相互调用的可靠性，以及分布式事务、全局锁、全局Id等，而单体系统不需要考虑这些复杂性。

4.分布式系统的应用都是集群化部署，会给数据一致性带来困难。

5.分布式系统中的服务通信依赖于网络，网络不好，会对分布式系统带来很大的影响。

6.分布式系统中，服务之间相互依赖，如果一个服务出现了故障或者是网络延迟，在高并发的情况下，会导致线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。由于服务的相互依赖，可能会导致整个系统的不可用，这就是雪崩效应。为了防止此类事件的发生，分布式系统必然要采取相应的措施，例如熔断机制。

1.4.2.熔断机制

在用SpringCloud构建的微服务系统中，采用了熔断器（即Hystrix令组件的CircuitBreaker）去做熔断。

例如在微服务系统中，有a、b、c、d、e、如果此时服务 b 出现故障或者网络延迟，服务b会出现大量的线程阻塞，有可能在很短的时间内线程资源就被消耗完了，导致服务b的不可用。如果服务b为较底层的服务，会影响到其他服务，导致其他服务会一直等待服务b的处理。如果服务b迟迟不处理，大量的网络请求不仅仅堆积在服务b，而且会堆积到依赖于服务b的其他服务。而因服务b出现故障影响的服务，也会影响到依赖于因服务b出现故障影响的服务的其他服务，从而由b开始，影响到整个系统，导致整个系统的不可用。这是一件非常可怕的事，因为服务器运营商的不可靠，必然会导致服务的不可靠，而网络服务商的不可靠性，也会导致服务的不可靠。在高并发的场景下，稍微有点不可靠，由于故障的传播性，会导致大量的服务不可用，甚至导致整个系统崩溃。

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

1.5.优点

1.将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界明确，代码的可读性和可扩展性增加。

2.微服务系统的微服务单元具有很强的横向扩展能力。

3.微服务可以采用任何的开发语言和技术来实现，提高开发效率、降低开发成本。

4.服务重写简单。

5.微服务的每个服务单元都是独立部署的，即独立运行在某个进程里，微服务的修改和部署对其他服务没有影响，大大减少了测试和部署的时间。

6.微服务在CAP理论中采用的是`AP``架构，具有高可用和分区容错的特点。

  • 高可用：主要体现在系统7x24小时不间断的服务，它要求系统有大量的服务器集群，从而提高了系统的负载能力。
  • 分区容错：使得系统更加健壮。

1.6.缺点

1.微服务的复杂度

2.分布式事务问题

3.服务的划分困难

4.服务的手动部署困难

1.7.设计原则

开闭原则与单一原则，架构设计和代码设计思路一样的

软件设计应该是渐进式发展。

  • 软件从一开始就不应该被设计成微服务架构，微服务架构固然有优势，但是它需要更多的资源。
  • 追求大公司所带来的技术解决方案，刻意地追求某个新技术，企图使用技术解决所有的问题，这些都是软件设计的误区。
  • 如果在LAMP单体构架够用的情况下，就应该用LAMP，因为它开发速度快，性价比高。
  • 随着业务的发展，用户量的增加，可以考虑将数据库读写分离、加缓存、加复杂均衡服务器、将应用程序集群化部署等。
  • 如果业务还在不断发展，这时可以考虑使用分布式系统，例如微服务架构的系统。

在微服务架构中，有三大难题，那就是服务故障的传播性（熔断）、服务的划分和分布式事务。

  1. 为了解决服务故障的传播性，一般的微服务框架都有熔断机制组件。
  2. 服务的划分没有具体的划分方法，一般来说根据业务来划分服务，领域驱动设计具有指导作用。
  3. 分布式事务一般的解决办法就是两阶段提交或者三阶段提交，不管使用哪一种都存在事务失败，导致数据不一致的情况，关键时刻还得人工去恢复数据。

总之，微服务的设计一定是渐进式的，并且是随着业务的发展而发展的。

2.SpringCloud

2.1.简介

SpringCloud作为Java语言的微服务框架，它依赖于SpringBoot，有快速开发、持续交付和容易部署等特点。SpringCloud的组件非常多，涉及微服务的方方面面。

SpringCloud在开发部署上继承了SpringBoot的一些优点，提高其在开发和部署上的效率。

Spring Cloud 的首要目标就是通过提供一系列开发组件和框架，帮助开发者迅速搭建一个分布式的微服务系统。

SpringCloud是通过包装其他技术框架来实现的，例如包装开源的Netflixoss组件，实现了一套通过基于注解、Java配置和基于模版开发的微服务框架。

SpringCloud提供了开发分布式微服务系统的一些常用组件，例如服务注册和发现、配置中心、熔断器、远程调用，智能路由、微代理、控制总线、全局锁、分布式会话等。

2.2.版本对应关系

每个springcloud和Springboot的版本之间是有对应关系的，如果版本对应关系不一致，会出现一些奇奇怪怪的问题。

2.3.常用组件

1.服务的注册和发现（eureka，nacos，consul）

2.服务的负载均衡（ribbon，dubbo）

3.服务的相互调用（openFeign，dubbo）

4.服务的容错（hystrix，sentinel）

5.服务网关（gateway，zuul）

6.服务配置的统一管理（config-server，nacos，apollo）

7.服务消息总线（bus）

8.服务安全组件（security，Oauth2.0）

9.服务监控（admin，jvm）

10.链路追踪（sleuth，zipkin）

2.4.总结

1.SpringCloud就是微服务理念的一种具体落地实现方式，帮助微服务架构提供了必备的功能

2.目前开发中常用的落地实现有三种

  1. Dubbo+Zookeeper半自动化的微服务实现架构 (别的管理没有)
  2. SpringCloudNetflix一站式微服务架构
  3. SpringCloudAlibaba新的一站式微服务架构

2.5.微服务架构图