python分布式服务系统框架_聊聊分布式系统架构
⼀、分布式系统的经典基础理论
1、分布式系统设计的两⼤思路：中⼼化和去中⼼化中⼼化：中⼼化的设计思想在⾃然界和⼈类⽣活中是如此的普遍和⾃然，它的设计思想也很简单，分布式集中的节点按照⾓⾊分⼯，可以分为两种⾓⾊--“领导”和“⼲活的”，中⼼化的⼀个思路就是“领导”通常分发任务并监督“⼲活的”，谁空闲了就给它安排任务，谁病倒了就⼀脚踢出去，然后把它的任务分给其他⼈；中⼼化的另⼀个思路是领导只负责⽣成任务⽽不再指派任务，由每个“⼲活的”⾃发去领任务。
去中⼼化：全球IP互联⽹就是⼀个典型的去中⼼化的分布式控制架构，联⽹的任意设备宕机都只会影响很⼩范围的功能。去中⼼化设计通常没有“领导”和“⼲活的”，⾓⾊⼀样，地位平等，因此不存在单点故障。实际上，完全意义的去中⼼化分布式系统并不多见，很多看起来是去中⼼化但⼯作机制采⽤了中⼼化设计思想的分布式系统正在不断涌现，在这种架构下，集中的领导是动态选择出来的，⽽不是⼈为预先指定的，⽽且在集发⽣故障的情况下，集的成员会⾃发举⾏会议选举新的领导。典型案例如：zookeeper、以及Go语⾔实现的Etcd。
2、分布式系统的⼀致性原理在说明⼀致性原理之前，可以先了解⼀下cap理论和base理论，具体见《事务与柔性事务》中的说明。
对于多副本的⼀致性处理，通常有⼏种⽅法：同步更新--即写操作需要等待两个节点都更新成功才返回，这样的话如果⼀旦发⽣⽹络分区故障，写操作便不可⽤，牺牲了A。异步更新--即写操作直接返回，不需要等待节点更新成功，节点异步地去更新数据，这种⽅式，牺牲了C来保证A。折衷--只要保证集中超过半数的节点正常并达到⼀致性即可满⾜要求，此时读操作只要⽐较副本集数据的修改时间或者版本号即可选出最新的，所以系统是强⼀致性的。如果允许“数据⼀致性存在延迟时间”，则是最终⼀致性。
如Cassandra中的折衷型⽅案QUORUM，只要超过半数的节点更新成功便返回，读取时返回多数副本的⼀致的值。然后，对于不⼀致的副本，可以通过read repair的⽅式解决。read repair：读取某条数据时，查询所有副本中的这条数据，⽐较数据与⼤多数副本的最新数据是否⼀致，若否，则进⾏⼀致性修复。此种情况是强⼀致性的。
⼜如Redis的master-slave模式，更新成功⼀个节点即返回，其他节点异步地去备份数据。这种⽅式只保证了最终⼀致性。最终⼀致性：相⽐于数据时刻保持⼀致的强⼀致性，最终⼀致性允许某段时间内数据不⼀致。但是随着时间的增长，数据最终会到达⼀致的状态。此种情况只能保证最终⼀致性。著名的DNS也是最终⼀致性的成功例⼦。
强⼀致性算法：1989年就诞⽣了著名的Paxos经典算法(zookeeper就采⽤了Paxos算法的近亲兄弟Zab
算法)，但由于Paxos算法难以理解、实现和排错，所以不断有⼈尝试优化算法，2013年终于有了重⼤突破：Raft算法的出现，其中Go语⾔实现的Raft算法就是Etcd，功能类似于zookeeper。
Base的思想：基本可⽤、柔性状态、最终⼀致性，主要针对数据库领域的数据拆分，通过数据分⽚(如Mycat、Amodeba等)来提升系统的可⽤性。由于分⽚拆分后会涉及分布式事务，所以接下来看⼀下如何⽤最终⼀致性的思路来实现分布式事务，也就是柔性事务。
3、柔性事务：具体见《事务与柔性事务》。
4、分布式系统的关键Zookeeper⽬标是解决分布式系统的⼏个问题：集集中化配置，集节点动态发现机制，简单可靠的节点Leader 选举机制，分布式锁。
ZNode有⼀个ACL访问权限控制列表，提供对节点增删改查的API，提供监听ZNode变化的实时通知接⼝--Watch接⼝。
ZNode类型：持久节点(可以实现配置中⼼)、临时节点(和创建这个节点的客户端会话绑定，可实现集节点动态发现，可以实现服务注册中⼼)、时序节点(创建节点时会加上数字后缀，通过选择编号最⼩的ZNode可以实现Leader选举机制)、临时性时序节点(同时具备临时节点和时序节点的特性，主要⽤于分布式锁的实现)。
⼆、分布式系统架构的主要内容
分布式系统架构的主要内容包括：RPC和对象序列化
分布式内存缓存技术、分布式内存计算
分布式存储
分布式计算
全⽂检索
消息队列
容器
1、RPC和对象序列化RPC设计的初衷是设计⼀套远程通信的通⽤框架，这个框架能够⾃动处理通信协议、对象序列化、⽹络传输等复杂细节，让开发者调⽤远程⽅法跟调⽤本地⽅法“看起来没什么区别”。
Java⾥经典的RPC实现⽅案是RMI，仅⽀持Java语⾔的客户端调⽤。
⼈类历史上，⽀持多语⾔通信的第⼀次伟⼤尝试造就了功败垂成的CORBA技术，1991年CORBA1.1诞⽣，直到1994年底才完成了CORBA2.0规范。
CORBA失败的原因可能包括：规范巨⼤⽽复杂，很难学习，开发过于复杂使得CORBA程序员稀缺，商业CORBA费⽤昂贵，很多公司开始转向Web浏览器、Java和EJB的电⼦商务基础设施等。同时，XML技术的兴起加速了CORBA的没落，SOAP使⽤XML作为RPC新的对象序列化机制，IBM则发扬光⼤推出WebService整套⽅案。
SOAP严格意义上属于XML-RPC技术的⼀个变种，SOAP是第⼀次真正成功解决了多语⾔多平台⽀持的开放性RPC标准。
但是SOAP报⽂复杂⽽且编码臃肿，由于它是⾯向机器识别的表达格式，最终导致了基于XML的SOAP协议和其上的WebService框架的末路，导致了基于JSON简单⽂本格式编码的HTTP REST通信⽅式的兴起。
HTTP REST慢慢侵占了RPC⼤部分领地，并导致了⼀度盛⾏的XML-RPC的灭绝；同时促进了正统RPC技术⾛向⼀个新的发展阶段，追求更⾼的性能及增加多语⾔多平台的⽀持，成为越来越多开源RPC框架的⽬标，⽐如Thrift、Apache Avro等开源框架。
当年CORBA墙倒众⼈推时，最初参与CORBA的⼀帮技术专家另起炉灶打造了延续⾄今的RPC之王--ZeroC Ice，作为RPC领域的王
者，ICE已经发展成⼀个很强⼤的微服务架构平台，在RPC通信领域⾥，性能第⼀，稳定性第⼀，多语⾔多平台⽀持。
与⼀般的HTTP REST框架不同，⼀个可⽤的RPC框架不仅解决了远程调⽤问题，也提供了⽤于服务注册和服务发现的基础设施，⽐如RMI ⾥的RMI Registry。服务注册、服务发现和服务监控后来成为通⽤分布式系统架构的核⼼和关键技术基础，也被赋予⼀个新概念--“服务治理框架”，最早的说法可能来⾃BAT的⼀些架构师。⽐如Dubbo就具备服务治理的能⼒，同时dubbo还提出了服务编排、服务降级、访问规则控制等，但实际上作为分布式系统最核⼼的仍然是：稳定、⾼性能的RPC通信及多语⾔⽀持。
如果⼀个分布式系统具备如下特点，则可以称之为“微服务架构”：1、任何⼀个服务都由多个独⽴的进程提供服务，这些进程可以分布在多台物理机上，任何进程宕机都不会影响系统提供服务；2、整个系统是由多个微服务有机组成的⼀个分布式系统，换⽽⾔之，不是⼀个巨⼤的单体应⽤。
当前主流的微服务架构可以分为三类：1、基于传统⾼性能RPC技术和服务治理的微服务框架，这个领域的王者是ZeroC IceGrid；2、以HTTP REST为通信机制的通⽤性微服务架构，最典型的为Spring Cl
oud；3、基于容器技术，没有提过特定的RPC通信机制，理论上任何分布式应⽤都可以运⾏在微服务架构平台上，⾔外之意就是要选择合适的通信协议，⽐如REST、Thrift、gRPC等，这个领域的王者是Google的Kubernetest。
微服务架构下，是否还需要Spring Framework？是否还需要MyBatis、Hibernate等数据映射框架？这个问题的答案不是特别确定，但有不少⼈倾向于不再使⽤这些框架来开发微服务，理由如下：1、微服务系统通常很多时候是互联⽹应⽤，CRUD操作少，查询操作多，因此Mybatis和Hibernate框架的优势不明显；2、微服务是系统中的重要⾻⼲，开发速度相对于微服务的实现品质来说并不重要；所以不少⼈倾向于直接采⽤原⽣JDBC来实现微服务的业务代码。
在对象序列化这块，JSON虽然是简单⽂本格式编码，但存在占⽤空间⼤、性能低下等特点，于是与语⾔⽆关的⾼效⼆进制编码协议成为热点技术之⼀。⾸先诞⽣了开源⼆进制序列化框架--MessagePack，是模仿JSON设计的⼀个⾼性能⼆进制的通⽤序列化框架。除了MessagePack，Google开源的多语⾔⽀持的Protocol Buffers编码协议也是这⽅⾯的代表作品。在Protocol Buffers之后，Google⼜开源了FlatBuffers，在性能、序列化过程中内存的占⽤⼤⼩、第三⽅依赖库的数量、编译后⽣成的中间代码数量等⽅⾯都做了⼤幅改进。Apache也发布了多语⾔的顶级RPC项⽬Apache Avro。
2、分布式内存缓存技术、分布式内存计算缓存系统常⽤的缓存淘汰策略：1、Least Frequently Used(LFU)策略--计算使⽤频率，优先淘汰最不常⽤的缓存条⽬，CPU的cache所采⽤的淘汰策略即为LFU策略；2、Least Recently Used(LRU)策略--淘汰最近最少使⽤的条⽬；
3、Adaptive Replacement Cache(ARC)策略--该策略由两个LRU组成，第1个LRU包含的条⽬是最近只被使⽤过⼀次的条⽬，第2个LRU包含的是最近被使⽤过⼆次的条⽬；
4、其他还有⼀些基于缓存时间的淘汰策略，⽐如淘汰存活时间超过5分钟的缓存条⽬。
分布式缓存都采⽤Hash算法进⾏数据分⽚，将数量庞⼤的缓存项均匀分布到集中的每个节点上，⽐如Redis3.0开始实现的分布式集功能就采⽤了Hash算法，将缓存项均匀分布到16384个Slot上去。以Redis2.x为基础改造的Codis是国内分布式缓存开源的⼀个典范，出⾃⾖瓣⽹。Memcache本⾝并没有提供集功能，但很多客户端Driver实现了Hash算法分配逻辑，因此也可以看成是⼀种分布式缓存的解决⽅案。
内存计算产品：商业的SAP Hana、开源的VoltDB等。VoltDB是⼀种开源的⾼性能的内存关系型数据库，提供社区版和商业版，是⼀种NewSql，是⼀个借鉴并基于HSQL的分配内存数据库集。
3、全⽂检索Lucence Core：Java编写的核⼼类库，提供全⽂检索功能的底层API与SDK。
Solr：基于Lucence Core开发的⾼性能搜索服务，提供了REST API的⾼层封装接⼝，还提供了⼀个Web管理界⾯。
PyLucene：⼀个Python版的Lucene Core的⾼仿实现。
ElasticSearch：也是基于Lucence的分布式全⽂检索中间件。
4、消息队列第⼀代消息队列：J2EE时代的产物，强调企业级特性，⽐如消息持久存储与事务的要求，都遵循JMS规范，最著名的是开源Apache ActiveMQ。虽然当前基于J2EE架构的企业软件少了，但依然有不少商业软件仍然采⽤了企业级的J2EE架构。值得⼀提的
是，ActiveMQ Artemis是ActiveMQ的下⼀代产品，它已经融合了多种MQ的特性，成为Java领域⽆法超越的MQ之王。
分布式和微服务的关系第⼆代消息队列：制定了⼀个开放性、免费的消息中间件协议AMQP标准，第⼀个也是最重要的开源AMQP消息中间件产品RabbitMQ，同时ActiveMQ⽬前也⽀持AMQP协议，Apache还专门开源了Qpid这个基于AMQP协议的消息中间件产品。
第三代消息队列：分布式系统设计理念，采⽤Zookeeper实现去中⼼化的集管理，以Kafka为代表。
5、微服务架构当前主流的微服务架构可以分为三类：1、基于传统⾼性能RPC技术和服务治理的微服务框架，这个领域的王者是ZeroC IceGrid；2、以HTTP REST为通信机制的通⽤性微服务架构，最典型的为Spring Cloud；3、基于容器技术，没有提过特定的RPC通信机制，理论上任何分布式应⽤都可以运⾏在微服务架构平台上，⾔外之意就是要选择合适的通信协议，⽐如REST、Thrift、gRPC等，这个领域的王者是Google的Kubernetest。
微服务架构的项⽬在实施过程中经常需要考虑的问题：引⼊⾃动化⼯具与集中运维管理⼯具，⽤于程序的编译打包、⾃动化部署和升级等⼯作；需要研究、测评⼤量相关开源⼯具并引⼊微服务架构中，原因是之前的很多中间件⼯具只适合于单体应⽤；团队重构，包括展现层和微服务层，建议团队中的⾻⼲技术⼈员成为微服务层的开发主⼒；⾼质量的⽂档。
基于消息队列的微服务架构：⽹易的蜂巢平台采⽤了基于消息队列的微服务架构，但基于消息队列的微服务架构案例少，没有知名的开源平台，因此实施成本⾼、风险⼤。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。