分布式系统/微服务

1.什么是微服务架构？

        微服务是系统架构上的一种设计风格，主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于http的restful API进行通信协作。

        被拆分成的每个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护者自身的数据存储、业务开发、自动化测试案例以及独立部署机制。

2.为什么要使用微服务？

单体开发缺点：1. 复杂性高
                         2.交付效率低
                         3.伸缩性(scalable)差
                         4. 可靠性差

        单体系统部署在一个进程内，修改一个很小的功能，为部署上线会影响其他功能的运行。单体应用中各功能模块的使用场景、并发量、消耗的资源类型各不相同，对资源的利用又相互影响，这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。

        单体系统虽然初期方便开发和使用，但随着系统的发展，维护成本会变得越来越大，难以控制。

当代企业级应用特点：设备激增，用户增多 
功能更多，更新频繁，业务复杂度何级增长
数据量趋于海量
系统稳定性要求更高，可用性要求极高

单体开发已经无法满足现在企业的要求。

        微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务，我们仅做最低限度的集中管理。                                                                          - 世界级软件架构大师 Martin Fowler

3.分布式系统

        分布式系统就是一组部署在同一个网络下的多个通过网络来通信和协调的组件，对外部而言表现的如同一个系统

分布式系统有多种层面的理解，比如，

       1） 可以指多个不同组件分布在网络上互相协作，比如前例所说的电商网站。

       2） 也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余，当数据修改时也需要通信来复制数据。

结论：

1. 微服务架构 是 分布式系统，分布式系统不一定是微服务架构
2. 应用系统当中，这两种的集群模式都有出现

4.CAP原理

        由加州大学的计算机科学家Eric Brewer 于1998年提出。指CAP这三个指标无法同时满足。

C：Consistency

        即一致性，访问所有的节点得到的数据应该是一样的。注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来。

A：Availability

        即可用性，所有的节点都保持高可用性。注意，这里的高可用还包括不能出现延迟，比如如果节点B由于等待数据同步而阻塞请求，那么节点B就不满足高可用性。

也就是说，任何没有发生故障的服务必须在有限的时间内返回合理的结果集。

P：Partiton tolerance

        即分区容忍性，这里的分区是指网络意义上的分区。由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。

5.BASE原理

        BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）。

        Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

6.Spring-Cloud

        Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具。它为微服务架构中涉及的服务治理、断路器、负载均衡、配置管理、控制总线和集群状态管理等操作提供了一种简单的开发方式。
1、外部或者内部的非Spring Cloud项目都统一通过API网关（Zuul）来访问内部服务。
2、网关接收到请求后，从注册中心（Eureka）获取可用服务。
3、由Ribbon进行均衡负载后，分发到后端的具体实例。
4、微服务之间通过Feign进行通信处理业务。
5、Hystrix负责处理服务超时熔断。
6、Turbine监控服务间的调用和熔断相关指标。