暂无个人介绍
> 搞了好多年的RPC框架有点疲了,最近在换到中间件的另一个方向MQ,准备做些kafka上阿里云的商业化工作,趁着热乎劲整理下kafka的知识,主要内容是阅读Kafka的作者之一Neha的书:The Definitive Guide的记录,加入一些其他参考。 >先说下Kafka名称来历, Kafka作者之一Jay是这么解释的:“我想既然 Kafka 是为了写数据而产生的,那么用作家的名字来命
> 继续上一篇 (空学Kafka之一)[https://www.atatech.org/articles/145913] ## 构建数据通道 ### 考量点 及时性,可靠性,吞吐量,安全性(通道安全,审计等),数据格式的上线兼容,ETL or ELT,统一还是专属(比如GoldenGate是oracle私有的,有很强的耦合性),优先选择Kafka Connect ###
### 来源 在对Dubbo新版本做性能压测时,无意中发现对用例中某个TO(Transfer Object)类的一属性字段稍作修改,由Date变成LocalDateTime,结果是吞吐量由近5w变成了2w,RT由9ms升指90ms。
### 环境配置 - Client与服务端分处两台ECS,配置为8C8G - OS:alios7.x86_64 - JDK:ajdk-8_6_11-b380 - 启动参数:-Xms1g -Xmx1g - 压测配置:同步调用(最常见的调用方式),200个客户端并发线程,预热30s,压测时长600s (10分钟) ### 若干解释 1. 本次压测是单对单的同步调用,
背景 应该是去年在摸索servicemesh时,看过些关于Kubernetes资料(主要是ppt载体的信息),也部署并体验了一番Openshift,同时留下过两篇关于servicemesh和Kubernetes的两篇文章。 Dubbo/HSF在Service Mesh下的思考和方案 Dubbo与kubernetes的集成思考 但个人感觉以前的了解是有点片面和零散(其实网上大多分享都
### 开头 Service Mesh这个“热”词是2016年9月被“造”出来,而今年2018年更是被称为service Mesh的关键之年,各家大公司都希望能在这个思潮下领先一步。今天我也分享阿里中间件在这方面的观点,思考和实践。考虑到有些人没了解过Dubbo(集团内以HSF为主)和Servicemesh,先简单介绍下这两个词。Dubbo应该是国内最受欢迎的远程服务框架,在Github上有超过