主流架构模型-SOA 架构和微服务架构

SOA 全称（Service Oriented Architecture）[['ɔ:rɪəntɪd][ˈɑ:kɪtektʃə(r)]]，中文意思为“面向服务的架构”，他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用跟 SOA 相提并论的还有一个 ESB（企业服务总线），简单来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；

SOA 所 解决 的 核心 问题
1. 系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】
2. 系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】
3. 业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

微服务架构
微服务架构其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。组件表示一个可以独立更换和升级的单元，就像 PC 中的
CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。如果我们把 PC 作为组件以服务的方式构建，那么这台 PC 只需要维护主板和一些必要的外部设备。CPU、内存、硬盘都是以组件方式提供服务，PC 需要调用 CPU 做计算处理，只需要知道 CPU 这个组件的地址即可。
 

微服务的特征
1. 通过服务实现组件化
2. 按业务能力来划分服务和开发团队
3. 去中心化
4. 基础设施自动化（devops、自动化部署）

SOA  和微服务架构的差别
1. 微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，同时 SOA 的思想进入到单个业务系统内部实现真正的组件化
2. Docker 容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似 Node或者 Spring Boot 等技术跑在自己的进程中。
3. 还有一个点大家应该可以分析出来，SOA 注重的是系统集成方面，而微服务关注的是完全分离领域驱动设计及业务驱动划分
 

领域驱动设计 的概念
领域驱动设计（DDD,Domain-Driven Design），软件开发不是一蹴而就的事情，我们不可能在不了解产品（或行业领域）的前提下进行软件开发，在开发前，通常需要进行大量的业务知识梳理，然后才到软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念
 

为什么需要  DDD
业务初期，功能大都非常简单，普通的 CRUD 就能满足，此时系统是清晰的。随着产品不断迭代和演化，业务逻辑变得越来越复杂，我们的系统也越来越冗杂。各个模块之间彼此关联，甚至到后期连作者都很难说清模块的具体功能意图是啥。导致在修改一个功能时，要追溯到这个功能需要的修改点就需要很长时间，更别提修改带来的不可预知的影响面。 

分布式架构的基本理论 CAP、BASE 以及应用
CAP  理论
一个经典的分布式系统理论。CAP 理论告诉我们：一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中两项。CAP 理论在互联网界有着广泛的知名度，也被称为“帽子理论”，它是由 Eric Brewer 教授在 2000 年举行的 ACM 研讨会提出的一个著名猜想：一致性（Consistency）、可用性（Availability）、分区容错（Partition-tolerance）三者无法在分布式系统中同时被满足，并且最多只能满足两个！
一致性：所有节点上的数据时刻保持同步
可用性：每个请求都能接收一个响应，无论响应成功或失败
分区容错：系统应该持续提供服务，即时系统内部（某个节点分区）有消息丢失。比如交换机失败、网址网络被分成几个子网，形成脑裂；服务器发生网络延迟或死机，导致某些 server 与集群中的其他机器失去联系分区是导致分布式系统可靠性问题的固有特性，从本质上来看，CAP 理论的准确描述不应该是从 3 个特性中选取两个，所以我们只能被迫适应，根本没有选择权；

总结：CAP 并不是一个普适性原理和指导思想，它仅
适用于原子读写的 NoSql 场景中，并不适用于数据库系统。

BASE  理论
从前面的分析中知道：在分布式（数据库分片或分库存在的多个实例上）系统下，CAP 理论并不适合数据库事务（因为更新一些错误的数据而导致的失败，无论使用什么样的高可用方案都是徒劳，因为数据发生了无法修正的错误）。此外 XA 事务虽然保证了数据库在分布式系统下的 ACID（原子性、一致性、隔离性、持久性）特性，但也带来了一些性能方面的代价，对于并发和响应时间要求比较高的电商平台来说，是很难接受的。eBay 尝试了另外一条完全不同的路，放宽了数据库事务的ACID 要求，提出了一套名为 BASE 的新准则。BASE 全称是 Basically available,soft-state,Eventually Consistent.系统基本可用、软状态、数据最终一致性。相对于 CAP 来说，它大大降低了我们对系统的要求。Basically available（基本可用），在分布式系统出现不可预
知的故障时，允许瞬时部分可用性
1. 比如我们在淘宝上搜索商品，正常情况下是在 0.5s 内返回查询结果，但是由于后端的系统故障导致查询响应时间变成了 2s
2. 再比如数据库采用分片模式，100W 个用户数据分在 5个数据库实例上，如果破坏了一个实例，那么可用性有 80%，也就是 80%的用户都可以登录，系统仍然可用
3. 电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现
soft-state（软状态）. 表示系统中的数据存在中间状态，并且这个中间状态的存在不会影响系统的整体可用性，也就是表示系统允许在不同节点的数据副本之间进行数据同步过程中存在延时； 比如订单状态，有一个待支付、支付中、支付成功、支付失败， 那么支付中就是一个中间状态，这个中间状态在支付成功以后，在支付表中的状态同步给订单状态之前，中间会存在一个时间内的不一致。Eventually consistent （数据的最终一致性），表示的是所有数据副本在一段时间的同步后最终都能达到一个一直的状态，因此最终一致性的本质是要保证数据最终达到一直，而不需要实时保证系统数据的强一致BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性