腾讯云开发者社区-腾讯云

开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

物流IT圈

专栏作者

280

文章

506101

阅读量

97

订阅数

分布式系统基石--幂等接口设计

随着互联网的发展，后台服务的承载量越来越大，性能多高的单台机器也无法满足无限制增长的承载量，同时互联网业务的特点往往要求服务快速扩容，如此这些特点，使得现在的后台架构越来越复杂。完全从单机演化到分布式系统。分布式系统常常使用RPC技术作为其通信基础，RPC与传统的单机版过程/函数调用不同，传统的单机函数调用，不是成功就是失败；而RPC却不只是是与非的问题，它又引入了第三态，超时(timeout)，超时的情况下，可能成功，也可能失败，换句话说，RPC的结果是未知的，超时情况下，可能会重试，这时候，接口的幂等性就是非常重要的了。

2019-12-05

6670

聊聊微服务的分布式通讯

分布式 rpc 数据库 sql 微服务

微服务目前比较热，但是微服务最难的还是可靠性问题，因为一个系统微服务可能几百个，网络调用频繁，网络的容错性就非常重要，因为对于分布式系统，需要默认网络环境是不可靠的，丢包或堵塞等情况都是可能会发生的，这里面其实就是经典的拜占庭将军问题，两个将军想约定某个时候一起进攻，但是不能确保这个信息能否可靠地传递给对方，是路途耽误了还是送信的人死了永远不可能送达，都无法确定，网络之间的通讯也是如此，A给B发个TCP数据包，这个数据包是因为网络繁忙暂时堵塞，还是就是被丢弃了呢？双方都不知道。

2019-09-05

5840

微服务的最终一致性与事件流

数据库 sql 微服务 rpc

微服务是指一个个单个小型业务功能的服务，由于各个微服务开发部署都是独立的，因此微服务天然是分布式的，因此，分布式系统的设计问题如CAP定理同样适合微服务架构，虽然微服务本身是无状态的，但是微服务是需要管理状态的。这些状态是指领域模型的状态或存储在自己的专有数据库中。虽然我们使用微服务必须面对分布式系统，但是好的一方面是有很多关于如何建立复杂分布式系统的成熟模式和最佳实践。典型的问题是微服务之间如果需要共享状态怎么办？实际是在分布式节点之间需要共享或复制状态。关于共享状态有几个解决方案： 1.微服务之间通过共享同一个数据库实现状态共享，但是因为微服务是使用自己专用的数据库，因此，数据库共享方案在微服务中是不适用的，违背了微服务架构宗旨。 2.通过调用同一个微服务实现状态共享，比如A服务和B服务需要共享C数据状态，而C数据状态是由C服务管理的，那么，A服务和B服务共同调用C服务不就是获得同一个C状态吗？但是考虑到分布式系统下，A服务和B服务可能不在同一个节点服务器上，或者不同Docker VM中，那么服务之间调用就需要网络通讯，通常RPC是一种通过网络调用远程服务器上其他服务的同步方式，但是，RPC虽然将网络编程藏起来，其实藏是藏不住，结果造成抽象泄漏了。 "Asynch message-passing makes constraints of network programming firstclass instead of hiding them behind the RPC leaky abstraction"异步消息传递使得网络编程变成第一公民(显式)，而不是像RPC隐藏了网络编程却造成抽象泄漏。在分布式系统中使用异步消息必然会遭遇最终一致性。甚至可以说微服务是使用最终一致性的(microservices use eventual consistency) 最终一致性Eventual Consistency 最终一致性是一种用于描述在分布式系统中数据的操作模型，在分布式系统中状态是被复制然后跨网络多节点保存，其实在关系数据库集群中，最终一致性被用来在集群多个节点之间协调数据复制的写操作，数据库集群中这种写操作挑战是：各个节点接受到的写操作必须严格按照复制的次序进行，这个次序是有时间损耗的，从这个角度看，数据库在集群节点之间的这种状态复制还是可以被认为是一种最终一致性，所有节点状态在未来某个时刻最终汇聚到一个一致性状态，也就是说，最终达成状态一致性。当构建微服务时，最终一致性是开发者 DBA和架构师频繁打交道的问题，当开始在分布式系统中进行状态处理时，头疼问题更加严重。核心问题是：如何在保证数据一致性基础上保证高可用性呢？事务日志几乎所有数据库都支持高可用性集群，大多数数据库对系统一致性模型提供一个易于理解的方式，保证强一致性模型的安全方式是维持数据库事务操作的有序日志，理论上理由非常简单，一个事务日志是一系列数据更新操作的动作有序记录集合，当其他节点从主节点获得这个事务日志时，能够按照这种有序动作集合重新播放这些操作，从而更新自己所在节点的数据库状态，当这个事务日志完成后，次节点的状态最终会和主节点状态一致。这种事务日志非常类似于财务中记账模型，或者类似银行储蓄卡打印出来的流水账，哪天存入一笔钞票（更新操作），哪天又提取了一笔钞票（更新操作），最后当前余额是多少（代表数据库当前状态）。 Event Sourcing Event sourcing事件溯源是借鉴数据库事务日志的一种数据持久方式，在ES中，事务单元变得更细粒度，使用一系列有序的事件来代表存储在数据库中的领域模型状态，一旦一个事件被加入事件日志，它就不能被移走或重新排序，事件被认为是不可变的，事件序列只能被追加方式存储。因为微服务将系统切分成一个个松耦合的小系统，每个系统后面都独占自己的数据库，虽然，微服务是无态的，但是它需要操作自己数据库的状态，如何保证微服务之间操作数据库数据的一致性成了微服务实践中重要问题，使用ES能够帮助我们实现这点。聚合可以被认为是产生任何对象的一致性状态，它提供校订方法用来进行重播产生对象中状态变化的历史。它能使用事件流提供分析数据许多必要输入，能够采取补偿方式对不一致应用状态实现事件回滚。事件流共享我们在微服务之间相互调用中通过引入异步机制，如果不同微服务之间存在共享的状态，或者说需要访问其他微服务的专用数据库，那么我们无需将本来专有的数据库共享出来，也无需在服务层使用2PC+RPC进行性能很慢的跨机同步调用，而是将改变这些共享状态的事件保存并共享，将领域事件以事务日志的方式记录下来，保存在一个统一的存储库，现在EventSourcing标准的存储库是 Apache Kafka。也就是说，微服务之间共享的不是传统数据库，而是Apache Kafka，通过读取ES的事务日志和重新播放，我们可以得到任何时

2019-07-30

1K0

【原创】传统SOA与微服务SOA之比对（一）

rpc 微服务企业

前段时间去某互联网公司面试，在CTO终面环节被问到一个关于服务治理的问题：请讲讲关于服务治理的经验，简述对SOA的一些看法。笔者正好在传统企业级系统架构下参与过相关SOA治理方案的制定与实施，同时在近年也有些许微服务方面的治理实践。遂在回答该问题时重点对两种不同场景下的治理进行的比较。现根据当时的回答做如下回忆整理：

2019-07-16

6480

多线程让可扩展性走进了死胡同

编程算法 rpc tornado 网站

这是一篇来自Python世界的文章，但是对整个编程领域还是适用的，多线程虽然让我们处理请求更快，但是也是有天花板的，绿色(微线程micro-thread)线程之类才是解决方案。多线程软件开发解决了大量的问题，尤其是以网络为中心的应用程序，这些程序需要严苛的性能快速响应用户。不幸的是，多线程并不足以解决大规模并发性的问题。解决这些问题需要改变编程模型，使用异步事件和基于回调机制。在Druva,我们创建了一个基于python库的名为Dhaga来解决大规模并发，而编程模型不需要重大改变。软件开发人员生活在一个并发的世界。线程如今是一等公民，今天在开发过程中，特别是当您的应用程序执行密集的网络运营，如同Druva一样的inSync系统(网络安全同步产品)。多线程帮助网络操作的编程代码流变得简单和顺序。当我们的应用程序需要增强的性能或改善其可伸缩性,我们可以增加线程的数量。但是当需要成千上万规模的并发请求,线程是不够的。我们发现多线程使用有以下缺点： 1. inSync系统客户端需要大量的文件通过网络RPC调用备份到服务器。开发人员加快速度的典型方法是使用线程。但多线程带来的性能却增加内存和CPU的使用成本;开发人员需要在速度和线程数之间保持一个平衡。 2.我们的服务器需要处理inSync系统与成千上万的客户之间并发连接和通知。为了有效地处理连接,我们使用线程来处理请求。但inSync系统客户的不断增加也意味着我们不得不继续增加线程的数量,从而消耗大量服务器的内存和CPU。 3.我们的Web服务器需要处理成千上万的平行的HTTP请求。大部分工作是在接收和发送的数据网络套接字并将其传给inSync系统的后端。导致大多数的线程等待网络操作。导致C10K问题，当有成千上万的同步请求到Web服务器，为每个请求生成一个线程是相当不可扩展的(Scale)。异步框架的限制许多异步框架,包括 Twisted扭曲、Tornado龙卷风和asyncore可以帮助开发人员远离使用线程的流行的方式。这些框架依赖非阻塞套接字和回调机制(类似Node.js)。如果我们按原样使用这些框架,我们Druva代码的主要部分必须重构。这不是我们想要做的事。重构代码会增加开发和测试周期,从而阻止我们达到规模要求。鉴于产品的多个部分需要大规模,我们每个人将不得不重构他们——因此增加一倍或两倍的努力。为了避免改变如此多的代码,我们不得不离开直接使用现有的框架。幸运的是,我们发现一些有用的工具。因为我们想要控制在网络I / O的代码执行,我们需要一种将一个线程划分为微线程micro-thread的方法。我们发现greenlets。它提供一种非隐式的微线程调度，称为co-routine协程。换句话说。当你想控制你的代码运行时它非常有用。您可以构建自定义计划的微线程，因为你可以控制greenlets什么时候yield暂停。这对我们来说是完美的,因为它给了我们完全控制我们的代码的调度。 Tornado是一个用Python编写的简单的、非阻塞的Web服务器框架,旨在处理成千上万的异步请求。我们使用它的核心组件,IOLoop IOStream。IOLoop是一个非阻塞套接字I / O事件循环;它使用epoll(在Linux上)或队列(BSD和Mac OS X)，如果他们是可用的,否则选择()(在Windows上)。IOStream提供方便包装等非阻塞套接字读和写。我们委托所有套接字操作给Tornado，然后使用回调触发代码操作完成(banq注：非常类似Node.js机制)。这是一个好的开始,但我们需要更多。如果我们在我们的代码中直接用上面的模块,我们大量的RPC代码将不得不改变，通过greenlets调度RPC，确保greenlets不要阻塞(如果greenlets堵塞，它会堵塞整个线程和其他全部),处理来自tornado的回调功能。我们需要一个抽象来管理和安排greenlets 以避免让它被外部调用堵塞，这个抽象能够超越线程达到大规模可扩展。这个抽象是Dhaga，它能让应用代码流编程起来像传统同步顺序，但是执行是异步的。 Dhaga(来自印地语,这意味着线程)是我们抽象的一个轻量级线程的执行框架。Dhaga类是来源于greenlet，使用堆栈切换在一个操作系统线程中执行多个代码流。一个操作系统的线程中使用协作调度执行多个dhagas。每当一段dhaga等待时(主要是等待一个RPC调用返回)，它yield控制权给父一级(也就是说,是创建它的操作系统级别线程的执行上下文)。然后父一级会调度安排的另一个dhaga准备运行。RPC调用将传递给tornado web服务器异步写入Socket，然后在其返回时注册一个回调，当这个RPC返回时，正在等待的dhaga将被添加到可运行队列中，然后后被父线程拾起。(banq注：类似node.js原理) 我们可以使用Dhaga代替线程

2019-07-16

8060

没有更多了

社区活动

RAG七天入门训练营

鹅厂大牛手把手带你上手实战

Python精品学习库

代码在线跑，知识轻松学

博客搬家 | 分享价值百万资源包

自行/邀约他人一键搬运博客，速成社区影响力并领取好礼

技术创作特训营·精选知识专栏

往期视频·千货材料·成员作品最新动态