原文地址：https://dzone.com/articles/building-microservices-with-akka-http-a-cdc-approa
众所周知，Akka系统是基于Actor模式的分布式运算系统，非常适合构建大数据平台。所以，无可避免地会出现独立系统之间、与异类系统、与移动系统集成的需求。由于涉及到异类和移动系统，系统对接的方式必
最近我们在一个项目上使用spray来发布restful service。 spray是个性能很好而且功能非常完整的service框架，包含很多组件，从底层http服务器到高层的rest路由DSL都有。
关于grpc，在前面的scalaPB讨论里已经做了详细的介绍：google gRPC是一种全新的RPC框架，在开源前一直是google内部使用的集成工具。gRPC支持通过http/2实现protobuf格式数据交换。protobuf即protocol buffer，是google发明的一套全新的序列化传输协议serialization-protocol，是二进制编码binary-encoded的，相对java-object，XML，Json等在空间上占有优势，所以数据传输效率更高。由于gRPC支持http/2协议，可以实现双向通讯duplex-communication，解决了独立request/response交互模式在软件编程中的诸多局限。这是在系统集成编程方面相对akka-http占优的一个亮点。protobuf格式数据可以很方便的转换成 json格式数据，支持对外部系统的的开放协议数据交换。这也是一些人决定选择gRPC作为大型系统微服务集成开发工具的主要原因。更重要的是：用protobuf和gRPC进行client/server交互不涉及任何http对象包括httprequest,httpresponse，很容易上手使用，而且又有在google等大公司内部的成功使用经验，用起来会更加放心。
akka 2.6.x正式发布以来已经有好一段时间了。核心变化是typed-actor的正式启用，当然persistence,cluster等模块也有较大变化。一开始从名称估摸就是把传统any类型的消息改成强类型消息，所以想拖一段时间看看到底能对我们现有基于akka-classic的应用软件有什么深层次的影响。不过最近考虑的一些系统架构逼的我不得不立即开始akka-typed的调研，也就是说akka-classic已经无法或者很困难去实现新的系统架构，且听我道来：最近在考虑一个微服务中台。作为后台数据服务调用的唯一入口，平台应该是个分布式软件，那么采用akka-cluster目前是唯一的选择，毕竟前期搞过很多基于akka-cluster的应用软件。但是，akka-cluster-sharding只能支持一种entity actor。毕竟，由于akka-classic的消息是没有类型的，只能在收到消息后再通过类型模式匹配的方式确定应该运行的代码。所以，这个actor必须包括所有的业务逻辑处理运算。也就是说对于一个大型应用来说这就是一块巨型代码。还有，如果涉及到维护actor状态的话，比如persistenceActor，或者综合类型业务运算，那么又需要多少种类的数据结构，又怎样去维护、管理这些结构呢？对我来说这基本上是mission-impossible。实际上logom应该正符合这个中台的要求：cluster-sharding, CQRS... 抱着一种好奇的心态了解了一下lagom源码，忽然恍然大悟：这个东西是基于akka-typed的！想想看也是：如果我们可以把actor和消息类型绑在一起，那么我们就可以通过消息类型对应到某种actor。也就是说基于akka-typed，我们可以把综合性的业务划分成多个actor模块，然后我们可以指定那种actor做那些事情。当然，经过了功能细分，actor的设计也简单了许多。现在这个新的中台可以实现前台应用直接调用对应的actor处理业务了。不用多想了，这注定就是akka应用的将来，还等什么呢？
上一篇讨论了SSL/TLS安全连接，主要是一套在通信层面的数据加密解决方案。但我们更需要一套方案来验证客户端。要把不能通过验证的网络请求过滤掉。
该文章介绍了在 AKKA 中，如何使用 Stream 进行高性能的 HTTP 文件上传/下载功能。首先，介绍了基于 Stream 的 HTTP 文件上传功能，它通过 chunk 进行小数据传输，能够充分利用网络带宽，提高上传速度。然后，介绍了基于 Stream 的 HTTP 文件下载功能，它通过将文件分块传输，能够充分利用网络带宽，提高下载速度。最后，总结了基于 Stream 的 HTTP 文件上传/下载功能在 AKKA 中的重要性，它能够提高系统的性能和可扩展性，同时能够降低系统的资源消耗，提高系统的效率。
在实际应用中，集群环境里共用一些数据是不可避免的。我的意思是有些数据可以在任何节点进行共享同步读写，困难的是如何解决更改冲突问题。本来可以通过分布式数据库来实现这样的功能，但使用和维护成本又过高，不值得。分布式数据类型distributed-data （ddata）正是为解决这样的困局而设计的。akka提供了一组CRDT（ConflictFreeReplicatedDataType 免冲突可复制数据类型）和一套管理方法来实现分布式数据在集群中的免冲突共享共用。
上次对restapi开了个头，设计了一个包括了身份验证和使用权限的restful服务开发框架。这是一个通用框架，开发人员只要直接往里面加新功能就行了。虽然这次的restapi是围绕着数据库表的CRUD操作设计的，但文件类数据在服务端与客户端之间的交换其实也很常用，特别是多媒体类如图片等文件类型。那我们就试着设计一个文件交换服务功能然后看看能不能很方便的加入到restapi框架内。
一个流程中，有两个重要子任务：一是数据迁移，将kafka实时数据落Es，二是将kafka数据做窗口聚合落hbase，两个子任务接的是同一个Topic GroupId。上游 Topic 的 tps 高峰达到5-6w。
一个流程中，有两个重要子任务：一是数据迁移，将kafka实时数据落Es，二是将kafka数据做窗口聚合落hbase，两个子任务接的是同一个Topic GroupId。上游Topic的 tps高峰达到5-6w。
有限状态机本身不是啥新奇东西，在GoF的设计模式一书中就有状态模式， 也给出了实现的建议。各种语言对状态机模式都有非常多种实现的方式。我自己以前用C++和java实现过，也以前把 apache mina 源代码中的一个状态机实现抠出来单独使用。
为了简化开发者和服务工程师维护Kafka集群的工作，yahoo构建了一个叫做Kafka管理器的基于Web工具叫做 Kafka Manager。 这个管理工具可以很容易地发现分布在集群中的哪些topic分布不均匀，或者是分区在整个集群分布不均匀的的情况。
从Scala的2.11.0版本开始，Scala的Actors库已经过时了。早在Scala2.10.0的时候，默认的actor库即是Akka。
上期说道：http/2还属于一种不算普及的技术协议，可能目前只适合用于内部系统集成，现在开始大面积介入可能为时尚早。不过有些项目需求不等人，需要使用这项技术，所以研究了一下akka-grpc，写了一篇介绍。本想到此为止，继续其它项目。想想这样做法有点不负责任，像是草草收场。毕竟用akka-grpc做了些事情，想想还是再写这篇跟大家分享使用kka-grpc的过程。
Akka-Cluster可以在一部物理机或一组网络连接的服务器上搭建部署。用Akka开发同一版本的分布式程序可以在任何硬件环境中运行,这样我们就可以确定以Akka分布式程序作为标准的编程方式了。
通信是分布式程序的血液和神经，就好比大脑发出的执行需要通过神经和需要才能传递到手脚进行执行。可见好的通信能力是分布式系统的重重之中。
前言 在Spark集群 + Akka + Kafka + Scala 开发(1) : 配置开发环境中，我们已经部署好了一个Spark的开发环境。 在Spark集群 + Akka + Kafka + Scala 开发(2) : 开发一个Spark应用中，我们已经写好了一个Spark的应用。 本文的目标是写一个基于akka的scala工程，在一个spark standalone的集群环境中运行。 akka是什么？ akka的作用 akka的名字是action kernel的回文。根据官方定义：akka用于r
该文介绍了如何使用Akka HTTP和SSE实现服务端推送文件给客户端的功能。首先介绍了SSE的概念和Akka HTTP的SSE库，然后通过一个具体的应用场景和代码示例详细讲解了如何实现该功能。
上面这段文字摘抄自 Akka 官网（akka.io），翻译成中文也就是：“Akka 是一个为 Java 和 Scala 构建高并发、分布式和弹性消息驱动应用程序的工具包”。而 Akka 具有的一切特性，其实都源自于一个用于处理并发计算问题的模型——Actor 模型。
在前面几篇讨论里我们介绍了scala-gRPC的基本功能和使用方法，我们基本确定了选择gRPC作为一种有效的内部系统集成工具，主要因为下面gRPC支持的几种服务模式： 1、Unary-Call：独立的一对client-request/server-response，是我们常用的http交互模式 2、Server-Streaming：client发出一个request后从server端接收一串多个response 3、Client-Streaming：client向server发送一串多个reques
Akka-http的客户端Api应该是以HttpRequest操作为主轴的网上消息交换模式编程工具。我们知道：Akka-http是搭建在Akka-stream之上的。所以，Akka-http在客
今天在intellij调试spark的时候感觉每次有新的一段代码，都要重新跑一遍，如果用spark-shell，感觉也不是特别方便，如果能像python那样，使用jupyter notebook进行编程就很方便了，同时也适合代码展示，网上查了一下，试了一下，碰到了很多坑，有些是旧的版本，还有些是版本不同导致错误，这里就记录下来安装的过程。
restapi作为前后端交互的枢纽：面对大批量的前端请求，需要确保回复的及时性。使用缓存是一项有效工具。我们可以把多数前端请求的回复response存入缓存，特别是一些需要大量计算才能获取的回复值，更可以大大提高后端的反应速度。值得庆幸的是akka-http已经提供了对缓存的支持，是基于java8 caffein的一套缓存操作工具包的。下面就介绍一下akka-http的caching。
该文介绍了如何利用Akka HTTP构建一个基于HTTP的RESTful API，该API使用Akka Streams来处理流式数据，并使用Akka HTTP来处理HTTP请求。同时，该文还介绍了如何使用Akka HTTP构建一个简单的Web服务器，并使用它来处理HTTP请求。
前面我们讨论过FSM，一种专门为维护内部状态而设计的Actor，它的特点是一套特殊的DSL能很方便地进行状态转换。FSM的状态转换模式特别适合对应现实中的业务流程，因为它那套DSL可以更形象的描述
props.put("group.id", "KafkaManagerOffsetCache")这句说明不管启动了几个kafka manager, 消费"__consumer_offsets"都使用同一个group. 解决方案: group.id从配置文件中读取,每个kafka manager使用不同的group id;
2、Master收到各Worker的注册信息后，会回复Worker已注册成功的信息
上期讨论过OAuth2, 是一种身份认证+资源授权使用模式。通过身份认证后发放授权凭证。用户凭授权凭证调用资源。这个凭证就是一种令牌，基本上是一段没什么意义的加密文，或者理解成密钥也可以。服务方通过这个令牌来获取用户身份信息，也就是说服务端必须维护一个已经获得身份验证的用户信息清单。研究了一下JWT，发现它本身可以携带加密后的一些信息包括用户信息，而这些信息又可以通过同样的加密算法解密恢复。也就是说服务端是可以直接对收到的JWT解密恢复用户信息，这样用起来就方便多了。还记着我们的POS例子里客户端必须构
在前面的主题中，我们解释了如何在大范围（in the large）内查看 Actor 系统，也就是说，如何表示组件，如何在层次结构中排列 Actor。在这一部分中，我们将通过实现设备 Actor 来在小范围（in the small）内观察 Actor。
该文摘要总结：本文介绍了如何利用Akka和Scala实现一个分布式计算系统，用于执行并行计算任务。具体来说，文章介绍了如何利用Akka的Actor模型和Scala的并发编程库来实现一个分布式计算系统，该系统能够执行多个计算任务，并将结果返回给调用者。同时，文章还探讨了如何利用Akka的Identify消息处理Actor的死亡，从而避免Actor的丢失，并提高系统的可用性。
该文章讲述了在技术社区中，从技术面试到工作交接的流程和注意事项。文章强调了技术社区的重要性，并描述了如何成为一名优秀的技术社区成员。
针对目前大家对OOM的类型不太熟悉，那么来总结一下各种OOM出现的情况以及解决方法。把各种OOM的情况列出来，然后逐一进行代码编写复现和提供解决方法。
来源: https://martinfowler.com/articles/patterns-of-distributed-systems/
ActorNormal重写createReceive函数，然后使用receiveBuilder构造一个接收器Receive，然后使用Receive的Match函数，对不同类型的请求进行分别处理；在处理内部可以使用 sender().tell发送返回值给请求者。
使用 Akka 可以让你从为 Actor 系统创建基础设施和编写控制基本行为所需的初级（low-level）代码中解脱出来。为了理解这一点，让我们看看你在代码中创建的 Actors 与 Akka 在内部为你创建和管理的 Actor 之间的关系，Actor 的生命周期和失败处理。
「Actor Model」为编写并发和分布式系统提供了更高级别的抽象。它减少了开发人员必须处理显式锁和线程管理的问题，使编写正确的并发和并行系统变得更容易。1973 年卡尔·休伊特（Carl Hewitt）在论文中定义了 Actors，然后通过 Erlang 语言所普及，并且在爱立信（Ericsson）成功地建立了高度并发和可靠的电信系统。
在分布式系统中，断路器（circuit breaker）用于提供稳定性和防止级联故障（cascading failures）。这些应该与远程系统之间的接口的超时一起使用（judicious timeouts），以防止单个组件的故障导致所有组件停机。
本文是我在中生代技术群分享的话题《创业一年经历的技术风雨》中的第三部分《研发团队总结的技术实践》。若要阅读第二部分《技术团队的管理》，请移步中生代技术群公众号。 与大多数团队相比，因为我们使用了小众的Scala，可以算得上是“捞偏门”了，所以总结的技术实践未必具有普适性，但对于同为Scala的友朋，或许值得借鉴一二。Scala社区发出的声音还是太小，有点孤独——“鹦其鸣也，求其友声”。 这些实践不是书本上的创作，而是在产品研发中逐渐演化而来，甚至一些实践会非常细节。不过，那个优秀的产品不是靠这些细节堆砌出来
我无可救药地成为了Scala的超级粉丝。在我使用Scala开发项目以及编写框架后，它就仿佛凝聚成为一个巨大的黑洞，吸引力使我不得不飞向它，以至于开始背离Java。固然Java 8为Java阵营增添了一丝亮色，却是望眼欲穿，千呼万唤始出来。而Scala程序员，却早就在享受lambda、高阶函数、trait、隐式转换等带来的福利了。 Java像是一头史前巨兽，它在OO的方向上几乎走到了极致，硬将它拉入FP阵营，确乎有些强人所难了。而Scala则不，因为它的诞生就是OO与FP的混血儿——完美的基因融合。 “Obj
完成了一套标准的rest风格数据库CRUD操作httpserver后发现有许多不足。主要是为了追求“通用”两个字，想把所有服务接口做的更“范generic”些，结果反而限制了目标数据库的特点，最终产生了一套功能弱小的玩具。比如说吧：标准rest风格getbyId需要所有的数据表都具备id这个字段，有点傻。然后get返回的结果集又没有什么灵活的控制方法如返回数量、字段、排序等。特别对MongoDB这样的在查询操作方面接近关系式数据库的分布式数据库：上篇提到过，它的query能力强大，条件组合灵活，如果不能在网络服务api中体现出来就太可惜了。所以，这篇博文会讨论一套专门针对MongoDB的rest-server。我想达到的目的是：后台数据库是MongoDB，通过httpserver提供对MongoDB的CRUD操作，客户端通过http调用CRUD服务。后台开发对每一个数据库表单使用统一的标准增添一套新的CRUD服务。希望如此能够提高开发效率，减少代码出错机会。
模拟实现基于文本界面的《客户信息管理软件》。 该软件 scala 能够实现对客户对象的插入、修改、删除、显示、查询（用 ArrayBuffer 或者 ListBuffer 实现），并能够打印客户明细表。
akka系统是一个分布式的消息驱动系统。akka应用由一群负责不同运算工作的actor组成，每个actor都是被动等待外界的某种消息来驱动自己的作业。所以，通俗点描述：akka应用就是一群actor相互之间发送消息的系统，每个actor接收到消息后开始自己负责的工作。对于akka-typed来说，typed-actor只能接收指定类型的消息，所以actor之间的消息交流需要按照消息类型来进行，即需要协议来规范消息交流机制。想想看，如果用户需要一个actor做某件事，他必须用这个actor明白的消息类型来发送消息，这就是一种交流协议。
使用NetworkClient连接到broker node, 使用selector处理网络IO;
前一段时间我们探讨了SDP的一个基于集群的综合数据平台解决方案，由多种数据库组成，包括：JDBC, Cassandra 及MongoDB。其中Cassandra和MongoDB属于分布式数据库，可以在集群中任何部署节点调用。而JDBC数据库则是非分布式的，无法部署在多个节点。假设我们把每种数据库的数据处理功能以微服务microservice形式提供出来的话，任何从其它集群节点对JDBC数据库微服务的调用都需要进行数据的序列化（serialization）。虽然Cassandra和MongoDB是分布式
在大数据程序流行的今天，许多程序都面临着共同的难题：程序输入数据趋于无限大，抵达时间又不确定。一般的解决方法是采用回调函数（callback-function）来实现的，但这样的解决方案很容易
akka-stream原则上是一种推式（push-model）的数据流。push-model和pull-model的区别在于它们解决问题倾向性：push模式面向高效的数据流下游（fast-dow
Flink on yarn 常见错误 1 Retrying connect to server 2 Unable to get ClusterClient status from Application Client 3 Cannot instantiate user function 4 Could not resolve substitution to a value: ${akka.stream.materializer} 5 java.lang.NoClassDefFoundError: org/
前言 做任何事情都不是想象中的那么简单。好久没有更新技术博客了，跟最近瞎忙有很大关系，虽说是瞎忙也抽空研究了些技术。 主要是前端渲染，像原生的WebGL和Cesium。WebGL写了几篇博客，自我感觉还可以。Cesium是一个封装好的WEB端3D Earth框架，有了WebGL的基础之后切换到Cesium按理说一切应该是顺理成章，简单的测试了几个功能之后发现确实非常好，简单的几行代码就可以实现Google Earth的功能，当然Google Earth重要的绝对不是他的渲染框架。 前期做了很多Geotrel
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
