01 分布式系统架构的冰与火

1.1  应用场景

首先，我们需要阐述一下为什么需要分布式系统，而不是传统的单体架构[即]。使用分布式系统主要有两方面原因

增大系统容量。我们的业务量越来越大，而要能应对越来越大的业务量，一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。所以，我们需要垂直或是水平拆分业务系统，让其变成一个分布式的架构。

加强系统可用。我们的业务越来越关键，需要提高整个系统架构的可用性，这就意味着架构中不能存在单点故障。这样，整个系统不会因为一台机器出故障而导致整体不可用。所以，需要通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性

当然，分布式系统还有一些优势，比如：

因为模块化，所以系统模块重用度更高；

因为软件服务模块被拆分，开发和发布速度可以并行而变得更快；

系统扩展性更高；团队协作流程也会得到改善；

……

不过，这个世界上不存在完美的技术方案，采用任何技术方案都是“按下葫芦浮起瓢”，都是有得有失，都是一种 trade-off。也就是说，分布式系统在解决上述问题的同时，也给我们带来了其他的问题。因此，我们需要清楚地知道分布式系统所带来的问题。

1.2 单体应用和分布式架构的优缺点

从上面的表格我们可以看到，分布式系统虽然有一些优势，但也存在一些问题。

-- 架构设计变得复杂（尤其是其中的分布式事务）。

-- 部署单个服务会比较快，但是如果一次部署需要多个服务，流程会变得复杂。

-- 系统的吞吐量会变大，但是响应时间会变长。运维复杂度会因为服务变多而变得很复杂。

-- 架构复杂导致学习曲线变大。

-- 测试和查错的复杂度增大。

-- 技术多元化，这会带来维护和运维的复杂度。

-- 管理分布式系统中的服务和调度变得困难和复杂。

也就是说, 分布式系统架构的难点在于系统设计，以及管理和运维。所以，分布式架构解决了“单点”和“性能容量”的问题，但却新增了一堆问题。而对于这些新增的问题，还会衍生出更多的子问题，这就需要我们不断地用各式各样的技术和手段来解决这些问题。这就出现了我前面所说的那些架构方式，以及各种相关的管理型的技术方法。这个世界就是这样变得复杂起来的。

这些架构方式和管理型的技术方法有:

各式各样的架构，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构、弹性化架构等。还有和这些架构相关的管理型的技术方法，如 DevOps、应用监控、自动化运维、SOA 服务治理、去 IOE 等。

但是, 其实，只要我们能够找到分布式这张网的“纲”，我们就能比较方便和自如地打开整张网了.

1.3 分布式系统的发展

从 20 世纪 70 年代的模块化编程，80 年代的面向事件设计，90 年代的基于接口 / 构件设计，这个世界很自然地演化出了 SOA——基于服务的架构。

SOA 架构是构造分布式计算应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。它采用开放标准与软件资源进行交互，并采用标准的表示方式。

开发、维护和使用 SOA 要遵循以下几条基本原则。

-- 可重用，粒度合适，模块化，可组合，构件化以及有互操作性。

-- 符合开放标准（通用的或行业的）。

-- 服务的识别和分类，提供和发布，监控和跟踪。

打卡01

21 | 分布式系统架构的冰与火

1.为什么需要分布式系统, 而不是传统的单体架构?

主要两个原因:

增大系统容量;

加强系统可用。

还有其他的优势好处.

模块化, 系统模块重用度更高；

软件服务模块被拆分，开发和发布速度可以并行而变得更快；

系统扩展性更高；

团队协作流程也会得到改善；

2. 分布式系统的发展历程

单体架构[软件模块高度耦合]-->SOA 架构[比较松耦合]--> 微服务架构[架构更为松耦合] [是以后的选择]

3. 编排和组织引擎方式?

通过工作流引擎，也可以是网关. 当然，还需要辅助于像容器化调度这样的技术方式，如 Kubernetes.

22 | 从亚马逊的实践，谈分布式系统的难点

1.从目前已经公开的资料来看，分布式服务化架构思想实践最早的公司应该是亚马逊。

2. 亚马逊如何做分布式服务架构的，遇到了哪些问题，以及是如何解决的?

亚马逊 CEO 杰夫·贝索斯（Jeff Bezos）就向全公司颁布了下面的这几条架构规定.

-- 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。

-- 团队间程序模块的信息通信，都要通过这些接口。除此之外没有其它的通信方式。其他形式一概不允许：不能直接链结别的程序（把--- 其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。

-- 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。

-- 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。

-- 不这样做的人会被炒鱿鱼。

备注:

这也应是 AWS（Amazon Web Service）出现的基因.

出现的问题:

-- 一个线上故障的工单会在不同的服务和不同的团队中转过来转过去。

-- 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都要做好配额和限流。

-- 监控和查错变得更为复杂。除非有非常强大的监控手段。

-- 服务发现和服务治理也变得非常复杂。

解决方法:

-- 分布式服务的架构需要分布式的团队架构

-- 分布式服务查错不容易

-- 没有专职的测试人员，也没有专职的运维人员，开发人员做所有的事情。

-- 运维优先，崇尚简化和自动化

-- 内部服务和外部服务一致。

备注:

在进化的过程中，亚马逊遇到的问题很多，甚至还有很多几乎没有人会想到的非常生僻的东西，它都一一学习和总结了，而且都解决得很好.

3. 分布式系统中需要注意的问题

问题一：异构系统的不标准问题

问题二：系统架构中的服务依赖性问题

问题三：故障发生的概率更大

问题四：多层架构的运维复杂度更大

重点: 分工不是问题，问题是分工后的协作是否统一和规范。

而且构建分布式服务需要从组织，到软件工程，再到技术上的一次大的改造，需要比较长的时间来磨合和改进，并不断地总结教训和成功经验。

TBD

3.1 把一个单体应用拆解成服务化或是微服务中遇到的问题和难点是什么？踩过什么样的坑？你是如何应对的？

网友评论

javaee

微服务通常根据业务来划分边界，粒度通常是一个独立的业务，具体多大合适不是一开始就决定的，这是一个逐步拆分细化的过程，李智慧老师说任何复杂的架构都是从最简单的应用慢慢演化过来的，就像当年的淘宝发展到现在。单体应用，为了高可用，需要集群多实例部署。查询太慢，访问太慢，加缓存，DB读写分离。业务发展到一定复杂程度，单体应用太庞大，会产生一系列问题。例如开发方面，一个工程几十上百人不停的改动，如何协作，一个人的代码有问题，影响了所有业务。每一个版本的迭代与发布，开发、测试、沟通得花大把时间，可能还会出错，牵一发而可能动全身。运维上，发布一次可以睡个午觉，发布一次影响线上所有功能。资源方面，扩容到几十上百台机器的时候，DB、NoSQL等的连接数撑爆了……//怎么理解? TBD

扩展问题:

Q: 分布式与集群的区别?

A: TBD

godtrue
单机在中间，往下研究是多线程高并发，往上研究是分布式高并发，往下是线程级别，往上是进程，集群级别，不过他们的根本是为了速度，为了快，为了快点将任务做完。//讲真的,这是一直不明白的地方之一

1:什么是分布式？
我认为相对单机而言，分布式至少是多机部署，多机共同分担任务处理

2:分布式核心解决的问题是什么？
我认为本质如浩哥所言，一是增加系统容量，二是实现系统高可用，其他还有并行开发、服务解耦

3:分布式引入的问题是什么？
数据不一致性，测试、运维复杂，排障链路长

4:分布式实现的难点是什么？
CAP

5:目前有哪些分布式的最佳实践？
不太清楚？

6:分布式必备技术有哪些？
RPC、MQ、各种集群存储系统、负载均衡、容器化部署

2018-12-29

3.2 什么是单体架构?

https://www.jianshu.com/p/92ca0bfbd52f  //单体架构,SOA架构,微服务架构,分布式架构,集群架构

后续补充

...

https://time.geekbang.org/column/article/1411  //21 | 分布式系统架构的冰与火

http://www.360doc.com/content/18/0509/10/40060546_752383974.shtml  //分布式与集群的区别

https://www.jianshu.com/p/92ca0bfbd52f  //单体架构,SOA架构,微服务架构,分布式架构,集群架构