分布式、集群、微服务、SOA概念理解

单体架构
传统软件
单体架构的好处
是开发、测试、部署⽅便，本地调⽤对于远程调⽤性能较好。
坏处
系统耦合性⾼，导致开发效率低下。
模块结构可能混乱，调用关系可能混乱。模块边界维护非常依赖个人水平。
不能根据需求选择更加合适的技术。例如要实现数据分析，应⽤的语⾔是 Java，那么就不能
利⽤到 Python 丰富的类库。

集群
集群，是指同一种组件的多个实例，形成的逻辑上的整体。
计算机集群将每个节点设置为执行相同的任务，由软件控制和调度。

集群中的数据库是各自独立的吗？
集群中的数据库不是相互独立的，一般我们经常看到的集群概念的应用就是：数据库集群；
具体如：读写分离时，使用的主从架构，主库和从库的数据一致；

分布式系统
分布式是指通过网络连接的多个组件，通过交换信息协作而形成的系统。
一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中，它们之间通过RPC方式通信。
wiki:
分布式系统是一组电脑，透过网络相互连接传递消息与通信后并协调它们的行为而形成的系统。

SOA
向服务的体系结构

微服务架构
微服务定义的提出：https://martinfowler.com/articles/microservices.html
和SOA一脉相称的。

分布式系统中包含的组件一定是各自不同的吗？
我赞同，以下观点。组件可以相同，只要进行消息的传递和协调行为就可以。

前面的答案说的不太准确，其实分布式不一定就是不同的组件，同一个组件也可以，关键在于是否通过交换信息的方式进行协作。比如说Zookeeper的节点都是对等的，但它自己就构成一个分布式系统。也就是说，分布式是指通过网络连接的多个组件，通过交换信息协作而形成的系统。而集群，是指同一种组件的多个实例，形成的逻辑上的整体。可以看出这两个概念并不完全冲突，分布式系统也可以是一个集群，例子就是前面说的zookeeper等，它的特征是服务之间会互相通信协作。是分布式系统不是集群的情况，就是多个不同组件构成的系统；是集群不是分布式系统的情况，比如多个经过负载均衡的HTTP服务器，它们之间不会互相通信，如果不带上负载均衡的部分的话，一般不叫做分布式系统。

作者：灵剑
链接：https://www.zhihu.com/question/20004877/answer/568581790

分布式和集群都是为了解决两个问题：
高吞吐量（throughput）
高可用（availability）

流行的分布式框架
Dubbo
SpringCloud

ZooKeeper,服务注册中心
Eureka，也是一种注册中心？

微服务

分布式和微服务的不同
自己目前的理解：
分布式不一定是微服务的，但是微服务肯定是分布式的。
原因：分布式强调了各个组件之间的信息传递和协作关系。没有强调服务之间的独立性。有可能分布式中的一些组件是可用共用数据库的。所以不一定是微服务的。但是微服务的定义就是多哥可以独立运行的模块组成一个完整的系统。所以一定是分布式的。

微服务架构的要求
微服务的规划与单体式应用程序十分不同，微服务中每个服务都需要避免与其他服务有所牵连，且都要能够自主，并在其他服务发生错误时不受干扰。
微服务是小而自治的，自治性的一个非常重要的特性就是独立部署，一个服务的修改和部署不应该对其他服务产生影响，但如果多个服务共享数据库，在数据库层的耦合让不确定性变大，一个服务对数据库结构的变更很有可能影响其他服务，即破坏了自治性。

为了更好的解决特殊场景的问题，微服务架构并不提倡使用适合所有场景的标准化技术，而是针对每个服务的特点，选择更合适的技术。

微服务中的每个服务，都是各自用自己的数据库吗？
答案是，确实如此。
每个微服务都需要独立的数据库。
原因：
微服务的定义中写到：
微服务架构风格的典型特征，如：技术异构（每个服务可以采用不同的编程语言或不同的数据存储技术）、独立部署和围绕业务能力构建，等等。

微服务架构的好处
1、因为服务颗粒比较细，而且技术异构。所以当一个服务可以用更好的技术实现，并且业务上有该需要时，可以使用更好的方案，平滑的过度。迭代代价小和灵活性大。、
2、不同服务可以有不同的迭代周期，适合互联网；

微服务架构的痛点
调试测试复杂
本地开发如果依赖别的服务会异常的难受，特别是你依赖的服务还依赖别⼈的服务，调试、
测试将变的复杂。
调⽤链路变⻓，调⽤增加了⽹络的开销
出错难以定位问题来源。因此你
需要引⼊分布式链路追踪服务来定位问题。

微服务和sidecar
将服务治理的功能放在 SideCar 即边⻋上，使得开发者专注于应⽤业务的开发，进⽽演进出 Service Mesh 即服务⽹格架构？

微服务和ELK
引⼊ELK来⽅便⽇志的查看，分析问题。
ELK技术栈（Elasticsearch、LogStash、Kibana）

微服务数据库的可弃性？
实践微服务有许多的做法，但其中一种做法是将数据库作为短期的存储空间而不是存储长期的资料。这意味着数据库可以在离线时被清空。因为它们可以在上线时从事件存储中心恢复，因此也能以存储器缓存（如：Redis） 作为数据库服务器。但这种做法需要将每个请求当作事件来进行广播。如此一来就可以从事件存储中心重播所有的事件来找回所有的资料。

CAP理论
C：数据一致性(consistency)
所有节点拥有数据的最新版本
A：可用性(availability)
数据具备高可用性
P：分区容错性(partition-tolerance)
容忍网络出现分区，分区之间网络不可达。

Docker和微服务
虽然使用一般的服务器虚拟化技术就能应用于微服务的管理，但容器技术 (Container Technology) 如 Docker 会更加地适合发展微服务的运算资源管理技术。