分布式架构的难点：
三态：第三种状态--超时
分布式事务：分布式情况下，业务原子性操作很可能是跨服务的，这样就导致了分布式事务
负载均衡：为达到高可用，每个服务都是多台机器运行
一致性：数据被分散或者复制到不同的机器上，如何保证各台主机之间的数据的一致性
故障的独立性：单个节点的故障不影响整体的服务
互联网系统术语：
响应时间(RT) ：系统对请求作出响应的时间。
吞吐量(TPS) ：系统在单位时间内处理请求的数量。
并发用户数 ：系统可以同时承载的正常使用系统功能的用户的数量。
QPS每秒查询率(Query Per Second) ：每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
SOA 架构和微服务架构
SOA （Service Oriented Architecture）：该架构包含多个服务，服务之间相互依赖最终实现一系列功能；一个服务通常以独立的形式存在于操作系统进程中，各个服务之间通过网络调用
SOA需要解决的问题:
- 我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如 ESB、以及技术规范、服务管理规范; 这一步解决的核心问题是【有序】。
- 我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是【复用】。
- 业务的服务化 : 我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 【高效】。
ESB（企业服务总线）：简单来说 ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通;
微服务架构
定义：微服务架构其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化(组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。)和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构和 SOA 架构非常类似,微服务只是的 SOA 升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。
微服务的特征:
- 通过服务实现组件化
- 按业务能力来划分服务和开发团队
- 去中心化
- 基础设施自动化(devops、自动化部署)
SOA 和和微服务架构的差别：
- 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线，同时以 SOA 的思想进入到单个业务系统内部实现真正的组件化。
- Docker 容器技术的出现，为微服务提供了非常便利的条件，比如更小的部署单元，每个服务可以通过类似 Spring Boot 或者 Node 等技术独立运行。
- 还有一个点大家应该可以分析出来，SOA 注重的是系统集成，而微服务关注的是完全分离。
分布式架构的基本理论
分布式一致性问题
一致性级别：
- 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入的是什么，读出来的也要是什么，用户体验好，但实现起来往往对系统的性能影响较大。
- 弱一致性：这种一致性级别约束了系统在写入成功后， 不保证立即可以读到写入的值，也不保证多久之后数据 能够达到一致，但会尽可能地保证到某个时间级别(如秒级别)后，数据能够达到一致状态。
- 最终一致性：最终一致性其实是弱一致性的一个特例，系统会保证在一定时间内，能够达到数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上用的比较多的一致性模型。
CAP 理论
一致性：所有节点上的数据时刻保持同步
可用性：每个请求都能接收一个响应，无论响应成功或失败
分区容错：系统应该持续提供服务，即使系统内部(某个节点分区)有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂、服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系。
CAP 理论告诉我们 : 一个分布式系统不可能同时满足一致性(C:Consistency)、可用性(A:Availability)及分区容错性(P:Partition tolerance) 这三个基本要求，最多只能同时满足其中两项。
BASE 理论（Basically Available,Soft-state,Eventually Consistent.）
Basically Available(基本可用)：表示在分布式系统出现不可预 知的故障时，允许瞬时部分可用性
Soft-state(软状态)：表示系统中的数据存在中间状态，并 且这个中间状态的存在不会影响系统的整体可用性，也就 是表示系统允许在不同节点的数据副本之间进行数据同步 过程中存在延时;
Eventually consistent(数据的最终一致性)：表示的是所有 数据副本在一段时间的同步后最终都能达到一个一致的状 态，因此最终一致性的本质是要保证数据最终达到一致， 而不需要实时保证系统数据的强一致
领域驱动设计及业务驱动划分（DDD,Domain-Driven Design）
DDD是一套综合软件系统分析和设计的面向对象建模方法
过去系统分析和系统设计都是分离的，DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。
在开发前，通常需要进行大量的业务知识梳理，然后才到软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计。
