微服务架构（MSA）产生背景

        早期常用框架为单体应用框架，所有代码都在同一项目开发、测试、部署，以项目为单位。当代企业级应用现状：设备激增，用户增多、功能多，更新频繁，业务复杂度几何级增加、海量数据、系统可用性与稳定性要求更高，使得单体项目开发效率大大降低，部署难度增加（项目变大后，编译测试 打包传输等环节都变慢，无法快速部署），可靠性下降等等，于是将单体项目拆分成多个微型应用，共同组成一个应用系统，即微服务架构。

微服务架构概述

        以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。微服务架构是一种分布式系统。
优点： 

  • 单体应用拆分成多个服务，整个 应用的复杂性被分摊到多个服务
  • 每个服务可以独立开发，选用不同的技术实现
  • 部署效率高，每个服务独立部署，不需要部署整个应用
  • 每个服务可以独立扩展，针对不同服务的 不同压力可以自由选择扩展

缺点：

  • 增加额外的复杂性。比如网络需要保证通畅；需要额外的通信失败处理等等
  • 测试也随着复杂度增加，测试某个应用需要额外开启多个相关应用
  • 某个服务的问题仍然会影响到其他服务，服务的调整需要仔细评估
  • 部署的复杂度增加，每个服务是一个独立系统，需要独立 配置数据库等基础设施

分布式系统概述

        是一组部署在同一个网络下的多个通过网络互相通信和协调的组件， 表现的如同一个系统。分布式系统有 三个指标，CAP，而这三个指标无法同时满足，这个结论称为CAP定理。（Consistency 一致性、Availability 可用性、Partition tolerance 分区容错性）

Consistency 一致性

        在分布式系统中的所有数据备份，在同一时刻是否同样的值。（访问任一节点得到的都是最新的数据副本）

Availability 可用性

        在集群中一部分节点故障后，集群整体是否还能正常响应客户端 的读写请求。（对数据更新具备高可用性）

Partition tolerance 分区容错性

        系统必须能够处理组件之间因为通信失败或者延迟而造成分区的情况。通信出现故障就会形成多个分区，此时系统无法同时保证数据的一致性和可用性。（三个节点，其中一个节点与另外两个节点无法通行，形成两个分区）

两个解决方案：

  • 暂停或关闭所有节点，等待网络恢复，数据达成一致，保证数据一致性。
  • 继续提供服务，保证可用性，那么访问将会得到不同的数据，不满足一致性

RPC（Remote Procedure Call）

        远程过程调用，通过请求另一个程序的服务而不需要了解底层的网络技术。是分布式系统解决远程通信的主要方式。常见的RPC框架：dubbo（阿里）、 gRPC（谷歌）、Thrift（Facebook）

BASE

        Basically Available(基本可用)，Soft State（软状态）、Eventually Consistent（最终一致性）