1.1 软件架构的演进：

                  |-- 单体架构

                  |-- SOA架构

        2.1 什么是微服务 （分布式系统，把业务划分成一个个独立能跑的小系统）

        2.2 微服务与SOA的区别（本质上还是SOA，但是不像SOA的总线一样，技术栈受限）

        2.3 微服务的优缺点

        2.4 微服务的开发框架

        3.1 服务通信（rest，rpc，异步队列）

        3.2 服务发现（客户端与服务端）

        3.3 常见问题

                    |-- 容错策略

                    |-- 服务限流

                    |-- 服务降级

                    |-- 服务链路追踪

                    |-- 熔断

                    |-- 负载均衡

                    |-- 服务监控

                    |-- 多级缓存

1.1软件架构演进 ：

  单体架构：（这个没什么说的，大家上手的项目应该都是这种架构）

    特点：

        1、所有的功能集成在一个项目工程中。

        2、应用与数据库分开部署。

        3、通过部署应用集群和数据库集群来提高系统的性能。

    优点：

        1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

    缺点：

        1、全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。

        2、系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

        3、技术栈受限。

        优化后的架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。

---

  SOA架构：

    特点：

        1、基于SOA的架构思想将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。

        2、各各项目（系统）与服务之间采用webservice、rpc等方式进行通信。

        3、企业服务总线（ESB）作为项目与服务之间通信的桥梁。

    优点：

        1、将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。

        2、可以针对不同服务的特点制定集群及优化方案。

        3、采用ESB减少系统中的接口耦合。

    缺点：

        1、系统与服务的界限模糊，不利于开发及维护。

        2、虽然使用了ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。

        3、抽取的服务的粒度过大，系统与服务之间耦合性高。

---

2.1什么是微服务：

        微服务，我们可以拆成微+服务两部分来看。微可以理解为细微、精细，服务代表它的作用，及提供服务，帮助完成整个系统的功能。

        综合来看，微服务是指将系统的功能点精细地划分为多个服务单独部署，降低服务间的依赖和耦合，减少单个服务的变更对整个系统的影响。另外一点非常重要的是，每个服务都以统一API的方式来供使用者使用，降低使用者的门槛，同时统一API框架里面也可以进行统一的信息采集以应用于系统的监控及稳定性保障。   

        （微服务架构的系统是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求）

2.2微服务与SOA区别联系

        微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。

        总结：微服务可以说是SOA的一种实现，将复杂的业务组件化。但它比ESB实现的SOA更加的轻便敏捷和简单。

---

2.3微服务的特点与优缺点：

    特点：       

        1. 每个微服务可独立运行在自己的进程里；

        2. 一系列独立运行的微服务共同构建起了整个系统；

        3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；

        4. 微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

    优点：

        1. 易于开发和维护（单个模块就相当于一个项目，只需要关心本模块就行）

        2. 启动较快（启动单个模块自然比启动全套要快了）

        3. 局部修改容易部署（低耦合，修改完后只需要重启局部单个模块）

        4. 技术栈不受限（3，4，5我感觉一个意思，都是解耦）

        5. 按需伸缩（不用考虑其他模块的情况）

    缺点：

        1. 运维要求较高 （毕竟分布式，出现问题几乎很难精确定位到是哪个模块）

        2.分布式的复杂性

        3.重复劳动（工具类几乎每个模块都有，无法重复利用代码）

---

2.4微服务开发框架

        Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）

        Dubbo：http：//dubbo.io

        Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）

        Consul、etcd&etc.（微服务的模块）

---

3.1服务调用（服务间的通信）

    restful

    RPC（Thrift, Dubbo）（远程过程调用，不懂略过）

    异步消息调用(Kafka, Notify)

3.2服务注册中心与服务发现

      服务注册中心，顾名思义，其主要功能是保存服务相关的信息，其中包括服务的功能描述，调用方式，部署情况等等。有了注册中心来保存服务的相关信息之后，接下来就可以解决服务发现的问题。服务发现，又一个新的知识点。

        【zookeeper可以充当一个服务注册表，让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端口）去访问具体的服务提供者）】

      服务发现，从字面意思上讲就是找到服务在哪里，专业一点可以理解为在调用微服务时的寻址过程，通过随机数，DNS解析等方式找到对应服务的ip和端口，然后发起调用。

        在服务发现的实现方式上，有两种模式，客户端模式和服务端模式。两者的本质区别在于，客户端是否保存服务列表的信息。

        客户端模式，即服务发现的过程发生在客户端。服务注册中心会将配置下发到各个客户端，并做到可以热更新，这样客户端在发起请求之前在本地的配置中找到准确的服务地址，然后发起调用。

        服务端模式，即服务发现的过程发生在服务端。每次调用时，调用方直接向微服务注册中心进行请求，服务注册中心再通过寻址并结合负载均衡策略对实际服务进行调用。

        下面通过两张图来形象的描述一下这两种模式。

、

3.3常见问题:

        分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。

    容错策略：

        快速失败：服务只发起一次待用，失败立即报错。通常用于非幂等下性的写操作

        失效切换：服务发起调用，当出现失败后，重试其他服务器。通常用于读操作，但重试会带来更长时间的延迟。重试的次数通常是可以设置的

        失败安全：失败安全， 当服务调用出现异常时，直接忽略。通常用于写入日志等操作。

        失败自动恢复：当服务调用出现异常时，记录失败请求，定时重发。通常用于消息通知。

        那么如何选择合适的方法呢？首先会考虑失败的阶段和原因，如果是服务查找阶段失败或者因为服务宕机失败，这时候一般不会采取重试。其他情况下，则需要考虑服务是否满足幂等性，如果不满足幂等性，也不会采取重试的方法。

    服务限流

        服务限流，这个概念理解起来很简单，当资源成为瓶颈时，我们需要限制服务的访问流量。

        做服务限流大致有两种方式，一种是静态流控，根据服务的预估最高可承载QPS和资源的情况来评估；另外一种则是动态流控，即根据服务运行的情况以及机器的各种指标来动态的评估每个服务的可支持流量，以此来进行流量控制。

        相比较而言，动态流控明显更智能一些。

    服务降级

        服务降级，即将某个服务停掉。

        停掉的原因通常有两种，一种是因为某个服务不重要，在请求高峰期，为保证核心业务的稳定运行，将边缘服务降级。另外一种是因为某个服务出现问题，如果继续访问可能会占用越来越多的资源，进而导致整个系统的梦亏，这种情况下也会进行服务降级。

        服务降级的做法比较灵活，既可以在客户端控制，又可以在服务端控制，而且服务降级是可逆的。

    服务链路跟踪

        服务链路跟踪，即我们可以跟踪每次请求具体涉及到服务，根据每次请求的唯一id可以有一个完整的调用日志链。

        做好服务链路跟踪之后，我们可以做到更快故障定位，可以更直观的分析调用链路中的关键点和风险点。同时，有了详细的调用来源和去向，我们可以做到更加细致的服务治理。

    服务监控

        监控这件事情就更好理解了，在任何架构中都是不可或缺的，在微服务架构中，我们同样需要对线上的运行情况做到全方位的监控。

    负载均衡

        随机

        轮询：每一个来自网络中的请求，轮流分配给内部的服务器，从1到N然后重新开始。此种负载均衡算法适合服务器组内部的服务器都具有相同的配置并且平均服务请求相对均衡的情况。

        加权轮询：根据服务器的不同处理能力，给每个服务器分配不同的权值，使其能够接受相应权值数的服务请求。例如：服务器A的权值被设计成1，B的权值是3，C的权值是6，则服务器A、B、C将分别接受到10%、30％、60％的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率，避免低性能的服务器负载过重。

        IP Hash：这种方式通过生成请求源IP的哈希值，并通过这个哈希值来找到正确的真实服务器。这意味着对于同一主机来说他对应的服务器总是相同。使用这种方式，你不需要保存任何源IP。但是需要注意，这种方式可能导致服务器负载不平衡。

    服务熔断：

        Circuit Breake（明哥查了下。。。断路器的意思）

        关闭：Circuit Breaker默认为关，允许操作正常执行 CircuitBreaker内部记录着最近失败的次数，如果达到某一程度，断路器的状态发生改变

        开启：执行后立刻报错抛出异常

        半开启：Circuit Breaker会允许执行一定数量的操作。如果所有操作全部成功，CircuitBreaker就会假定故障已经恢复，它就会转换到关闭状态，并且重置失败次数。如果其中 任意一次 操作失败了，Circuit Breaker就会认为故障仍然存在，所以它会转换到开启状态并再次开启计时器（再给系统一些时间使其从失败中恢复）

    多级缓存：

        缓存击穿问题