左耳听风_022_21_分布式系统架构的冰与火
你好，我是陈浩网名猪耳朵house.呃，最近几年呢我们一直在谈论各式各样的架构，如高并发架构、异地多活架构、容器化架构、微服务架构、高可用架构，还有弹性化架构等等。
还有呢和这些架构相关的管理型的技术方法，比如divops应用监控、自动化运维、SOA服务治理去IOE啊等等。
那面对这么多纷乱的技术，我看到很多团队或者公司啊都是一个一个的去做这些技术啊，非常辛苦，也非常累。
那这样的做法呢，就像我们在撑开一张网里面的一个一个的网眼。
那其实呢只要我们能够找到这张网的缸，我们就能比较方便和自如的打开整张网了。
那么这张分布式大网的总线啊，也就是缸在哪里呢？我希望通过这一系列的课程啊，可以让你能找到这个缸，从而呢能让你更好更有效率的做好架构和工程。
首先呢我们需要阐述一下为什么需要分布式系统，而不是传统的单体架构。
也许这对你来说啊已经不是什么问题了。
但是呢请允许我在这里重新说明一下使用分布式系统啊主要有两方面的原因。
那一方面呢是增大系统容量，我们的业务量越来越大要能应对越来越大的业务量。
一台机器的性能已经无法满足了，我们需要多台机器才能应对大规模的应用场景。
所以呢我们需要垂直或者水平拆分业务系统，让它变成一个分布式的架构。
那另一方面原因呢是加强系统可用性。
我们的业务越来越关键，它就需要提高整个系统架构的可用性。
那这个呢就意味着架构中啊不能存在单件故障。
那这样的话，整个系统啊就不会因为一台机器出故障而导致整体不可用。
所以需要通过分布式架构来冗余系统，以此来消除单件故障，从而提高系统的可用性。
当然啊分布式系统还有一些优势啊，首先呢是因为模块化，所以系统模块重用度啊更高。
那其次呢，因为软件服务模块被拆分开发和发布速度啊可以并行而变得更快。
那另外呢分布式系统的系统扩展性更高，那还有呢就是团队协作流程啊也会得到改善。
不过呢这个世界上不存在完美的技术方案，采用任何技术方案啊，都是按下葫芦浮洗瓢啊，都是有得有失，都是一种trade off.也就是说呢，分布式系统啊在解决那些问题的同时啊，也给我们带来了其他的问题。
因此呢我们需要清楚的知道分布式系统所带来的问题。
我在这里呢用了一张表格啊比较的单体应用和分布式架构的优缺点。
从表格中我们可以复杂。
那布式系统虽然有一些优势啊，但也存在着一些问题。
那第一个问题呢就是架构设计变得复杂啊，尤其是其中的分布式事务。
那第二呢是部署单个服务啊会比较快。
那第四呢，如果一次部署需要多个服务啊，流程啊就会变得复杂。
那第三呢是系统的吞吐量会变大，但是响应时间呢会变大。
那第四呢运维复杂度啊也会因为服务变多而变得很复杂。
那第五个问题呢，就是架构复杂，导致学习曲线变大了。
那第六个问题呢就是测试和查错的复杂度啊也增大了。
那第七呢就是技术多元化，会带来维护和运维的复杂度。
那另外呢还有一个问题，就是管理分布式系统中的服务和调度啊变得困难和复杂。
也就是说呢，分布式系统架构的难点啊在于系统设计、管理和运维。
所以呢分布式架构解决了单点和性能容量的问题，但是却新增了一堆问题。
而对于这些新增的问题呢，还会衍生出更多的子问题。
那这个呢就需要我们不断的用各式各样的技术和手段来解决这些问题。
那这样呢就出现了我前面所说的那些架构方式，还有呢各种相关的管理型的技术方法。
那这个世界啊就是这样变得复杂起来了。
那接下来呢我们再谈一谈分布式系统的发展。
从二十世纪七十年代的模块化编程，八十年代的面向事件设计，九十年代的基于接口和构建设计。
那这个世界啊很自然的就演化出了SOA啊，也就是基于服务的架构。
Sov架构呢是构造分布式计算应用程序的方法，它把应用程序功能作为服务发送给最终的用户或者其他的服务。
它采用了开放标准与软件资源进行交互。
第三呢，采用标准的消息服式。
那开发、维护和使用SOV啊需要遵循以下几条基本原则。
那第一呢要可重用啊，力度合适、模块化，可组合，构建化和友互操作性。
第二呢，要符合通用的或行业的开放标准。
第三呢在于服务的识别和分类，提供和发布、监控和跟踪。
但IBM搞出来的SOV啊非常重，第以对SOV的裁剪和优化从来没有停止过。
比如之前的SVPWSDL和擦描这样的东西啊啊基本上已经被抛弃了，而改成了restful和jason这样的跟踪。
而企业服务总线ESB这样非常重要的东西呢，也被简化成了pub和sub的消息服式。
不过呢SUV的思想啊一直延续着，所以呢我们现在啊也不说SOV了，而是说分布式服务架构了。
那文中呢就有一张SV架构的演化图。
我们可以看到啊，面向服务的架构呢有三个阶段。
那第一个阶段呢是在二十世纪九十年代之前，是单体架构，软件模块呢高度耦合。
那当然呢这张图啊也同样说明了，有的SSV架构呢其实和单体架构没什么两样。
因为都是高度耦合在一起的，就像图中的齿轮一样。
当你调用一个服务的时候呢，这个服务啊会调用另一个服务，然后呢又调用另外的服务，于是整个系统啊就转起来了。
但是本质上这是比较耦合的做法。
那第二个阶段呢是在两千年左右出现了比较松耦合的SOV架构。
那这个架构呢需要一个标准的协议或者中间件来联动其他相关联的服务，比如ESB.那这个一来呢服务间并不直接依赖，而是通过中间件的标准协议或者通讯框架来相互依赖。
那这个呢其实就是LC控制反转和DIP依赖倒置原则的设计思想在架构中的实践。
他们都赖于一个标准的协议啊，或者一个标准统一的交互方式，而不是直接调用。
在第三个阶段呢啊也就是在二零一零年之后，出现了微服务架构。
这个架构呢更为松耦合。
每一个微服务呢都能独立完整的运行啊，也就是所谓的自包含后端单体的数据库呢也被微服务这样的架构啊分散到不同的服务中。
在它和传统SOV的差别呢，在服务间的整合啊，需要一个服务编排或者服务整合的引擎。
啊，就好像是在交响乐中呢，就需要有一个指挥来把所有的乐器啊编排和组织在一起。
那一般来说呢，这个编排和组织引擎啊可以是工作流引擎啊，可以是网关。
那当然呢还需要辅助像容器化调度啊这样的技术方式。
比如coubernetice在marketing flder mmicroservices这篇文章中呢啊就是详细的描述。
我在文中呢也给你提供了链接，微服务的出现呢使得开发速度变得更快，部署快，隔离性高，系统的扩展度啊也很好，在在集成测试运维和服务管理等方面就比较麻烦了。
所以呢就需要一套比较好的微服务pass平台啊，就像spring cloud一样，需要提供各种配置服务服务，发现智能路由控制总线等等。
还有呢像cooper netice提供的各式各样的部署和调度方式。
那如果没有这些pass层的支撑呢，微服务啊也是很难被管理和运维的。
好在今天的世界呢已经有了具备这些方面的基础设施，所以采用微服务架构啊，我认为只是一个时间问题了。
好了，今天的内容就到这里。
那相信通过今天的学习呢，你应该已经对为什么需要分布式系统，而不是传统的单体架构这一问题啊有了清晰的认识。
并且呢对分布式系统的发展历程啊了然于心。
那在下一节课呢，我将结合亚马逊的分布式架构实践，来谈一谈分布式系统架构的技术难点和应对的方案。
我列出了分布式系统架构的本质系列文章的目录，呃，希望你呢能在这个列表里找到自己感兴趣的内容。
那第一篇呢是分布式系统架构的冰与火。
那第二篇呢从亚马逊的实践谈分布式系统的难点。
第三篇呢是分布式系统的技术栈，第四篇呢是分布式系统关键技术，全栈监控。
第五篇呢是分布式系统关键技术服务调度。
呃，第六篇呢是分布式系统关键技术流量与数据调度。
第七篇呢是洞悉pass平台的本质。
第九篇呢是推荐阅读分布式系统架构经典资料。
第九篇呢是推荐阅读分布式数据调度相关论文。
在本节课的最后呢，我很想听一听大家在进行分布式系统开发，把一个单体应用拆解成服务化或者微服务中所遇到的问题和难点是什么啊，踩过什么样的坑，你呢是如何应对的？欢迎在留言区留言。