怎么学习分布式系统的知识
分布式系统学习的大障碍
干IT的程序员都知道学习意味者涨薪，干IT的人都有一种感觉代码在手天下我有的感觉。但是我们都知道学习技术最大的难点就是坚持不下去，好不容易学习完了还没地方施展，学的东西过个几天就忘的差不多了。我也是挣扎在IT技术海洋的一个痴儿。开通这个学习分布式系统的专栏有两个目的：第一是要记录自己学习的笔记和历程，第二是整理一份自己的学习分布式系统的一些系统笔记方便广大的读者更轻松的学习IT技术。
分布式系统的由来
分布式系统的行业现状
其实近些年在IT圈最流行的各种技术名词和概念。刚刚开始学习这些新的新的技术的时候我们都是很茫然，什么微服务、SOA、区块链等技术。我通过从网上查找或者购买的一些知识付费的专栏或者工作中和同事的探讨逐渐的摸清了这些技术的一个大概轮廓。接下来说说的仅属于个人见解，首先声明本人虽然在本行干了多年，但是不是什么技术大牛或者某个大厂的架构师等等。所以如果有什么什么错误或者不当烦劳大佬们指正小弟。你们是我技术生涯的指路的明灯。
最近我发现不管是面试还是本行业同行的交流都在讨论微服务、SOA、异地多活、链路跟踪、自动化运维、应用监控、分布式缓存等等名词。第一感觉就是很牛掰。但是都是干嘛的，我听到这些第一感觉就是很牛逼，但是都是干嘛用的。我现在写的业务代码根本不用这些干嘛要弄这么复杂（本人一直在小公司工作，没见过什么市面）。但是随着不断的学习越来越理解这些东西存在必要性。任何技术活架构的存在都不是偶然，脱离业务的技术是没有价值的，任何技术的存在都是依附与业务。就连我们认为用处不大的算法都是为了业务的存在，因为现在封装的技术或者框架太多了所以让我觉得我们只要框架用的好什么业务都可以完成。话说回来如果框架及其难用或者没有框架我们该何去何从？前面的废话太多下面我们来系统的阐述以下我理解的分布式系统。
分布式系统的演变
说到分布式系统的我们务必要了解一下单体架构。因为单体架构满足不了我们的业务来所以逐渐的演变诞生来分布式系统架构。
举个例子：单体系统就像一个初创公司，分布式系统就像分布式系统，
初创公司中仅仅有那么几个人每个人都是身兼多职。当然这个公司的盈利是非常有限的。当有一天这个初创公司做成了一定的规模，他们的业务也比较多，再也不是那种一个人或者两个人就可以完成应有的工作了，管理上也会越来越乱。所以这个时候就需要扩大人员规模，公司部门化，这样我们要做一项工作只需要将规定的部分分给某个部门去做，然后向这个部门去要指定的工作成果，将每个部门做的成果组装到一块就可以完成指定的业务工作，部门化也方便了人员管理。
同样最开始单体应用架构会把所有的业务都在一个服务上完成。当用户量小的时候这个服务还可以正常运行，但是当用户量逐步上来的时候这种单体架构的服务会越来越吃力直至最后不堪重负到最后的崩溃。这个时候我们的服务器就类比我们公司里面招的人，一个人完成不了那么我们就去招两个人或更多，既然一台服务器满足不了这么多用户量的需求那么我们去买两台服务器去共同处理共同分担这么多的用户量。购买服务器的成本就像我们招人需要发工资一样。既然我们需要将工作分配到每个服务器上那么我们就会需要一个分配机制去分配用户请求，服务器不像我们人类这么只能几个人一协商把工作一分配就可以各干各的活，所以这其中需要我们去搭建一个负载均衡的服务去分配请求。但是其中还是有个问题就是我们的系统中可能有多中业务，比如其中A业务和B业务模块，但是A业务的用户请求比较多热度高，需要10台服务器去承载，但是B业务使用的人很少，一台服务还有余。这样我们的服务器资源就得不到很好的利用。公司中财务需要2个人就够了销售需要10个人，这个时候不能说我直接拷贝原公司的样子再创建多个一摸一样的公司吧，销售的确实是够了但是多出来的财务人员就是天天没事干浪费成本。所以这个时候就会进行业务拆分将A模块和B模块拆分成服务，这个时候就可以针对不同的服务进行服务器的扩充。所有的业务在一个服务中还有一个弊端就是各个模块之间的依赖性太强而且模块的，当其中一个地方出现问题那么就会导致整个系统的崩溃。而且模块的重用度比较低。所以我们开始了模块服务化，多服务器支撑同一个业务的架构指路也就是我们的分布式架构。
分布式架构是一种比较广泛的架构理念。我们以上所说的各种技术都是在分布式架构理念的基础上衍生出来的。比如说SOA(面向服务的架构)，MSR（微服务）。分布式架构给我们解决了系统吞吐量和系统稳定性的问题但是也带来了一些其他问题比如架构复杂，部署运维复杂等问题，出现问题之后排查耗时。之后出现的大部分技术或概念都是针对分布式架构带来的新的问题而出现的，以下是单体架构和分布式架构的对比。
| 优点/缺点 | 单体架构 | 分布式架构 |
|---|---|---|
| 功能开发 | 耗时 | 效率高耗时短 |
| 部署/运维 | 简单容易 | 复杂耗时 |
| 性能 | 响应快吞吐量小 | 响应慢吞吐量大 |
| 技术 | 技术单一简单 | 技术面广深度大 |
| 系统扩展性 | 差 | 优秀 |
| 系统管理 | 重点在开发 | 重点在部署和后期运维 |
分布式系统介绍总结
1 分布式解决问题
1.1 增加系统的可用性
1.2 增加系统的吞吐量
2 微服务和SOA都是实现分布式系统的一种架构方案
SOA 和 MSR的对比
SOA和MSR如果不仔细区分还真的不知道区别在哪，之前我记得我面试的时候就被这种面试题给问懵了，当时概念差不多能说出来但是区别的化真的感觉就是一样的。这两种架构技术的出现的原因都是为了解决分布式架构中出现的问题。
按照我的理解SOA和微服务本质上都是将系统模块服务化，拆分业务模块成服务，SOA面向服务的架构主要是实现服务之间的整合，其整合模式是按照固定的协议和中间件（企业总线ESB）进行服务之间的信息交互。还是举例子，一个小区内要进行交流中间又一个信箱每个格子都是针对一个门，那么其中信箱就相当与企业服务总线每个信箱格子都是针对一个门牌号就相当与协议。通过信息进行交流。
微服务也是将业务模块拆分服务化，不过服务之间的组合有点不一样需要一个服务编排或服务整合的服务。就好像网关服务进行请求的分发和鉴权等作用。相对于SOA而言和业内的案例而言微服务针对的业务更为复杂所以服务拆分的粒度相对较大，比较松耦合。
两者之间的区别类比与公司，SOA就像公司部门化，微服务就像部门公司化。公司部门化，公司中分出了各个部门每个部门负责一个职能，那么当我们各个部门进行重大信息交流的时候就会进行开会，这个会议就像ESB（企业消息总线）所有的指令和任务信息都是在会议上发送给各个部门的。部门公司化，当人员过多之后可能会将每个部门成立一个公司然后将各个公司分散到各地也就是分公司，这个时候会议已经不能实现信息的试试交互了，这个时候公司会有一个公司总部，当需要某个分公司去完成某个任务的时候都是通过总公司去下发任务通知分公司。这个公司总部就像是服务编排和整合服务。
微服务的出现使得开发速度变得更快，部署快，隔离性高，系统的扩展度也很好，但是在集成测试、运维和服务管理等方面就比较麻烦了。所以，需要一套比较好的微服务 PaaS 平台。就像 Spring Cloud 一样需要提供各种配置服务、服务发现、智能路由、控制总线……还有像 Kubernetes 提供的各式各样的部署和调度方式。
本章小结：
1. 分布式系统
- 解决的问题
- 系统稳定性
- 系统吞吐量
- 带来的问题
- 架构设计复杂
- 部署运维麻烦
- 实现方案
- SOA
- 微服务
2. SOA和微服务的对比和区别
- SOA架构：服务件的组合交互通过固定协议和中间件（ESB企业服务总线）进行信息交互，服务拆分粒度相对较小
- 微服务： 服务之间的整合和交互通过一个服务编排或组合的服务进行整合，拆分的粒度比较小。
总结
分布式系统介绍到这，仅仅对分布式系统的认识进行了一个宏观的介绍。下一章将细化分布式系统设计的一些关键 部分和技术栈，比如缓存系统、异步消息系统 、负载均衡、数据景象等。本人小公司菜鸟一枚希望找到志同道合的同行多多交流多进步。如有错误枉指正。