2013

2023-01-14 23:38:08 鲁迅写了一句“夫天地者”,后面没有接着写下去.

《三部曲之世界》

2017年年初开始发布第一篇,直至2019年年终结束,整3年,这一阶段对于邱永臣而言,非常重要(从生活事业稍有起色,到最终陷入低谷、一无所有)。

具体篇章发布于知乎,因文化审查等各种原因,部分篇章稍有删漏,详见:知乎专栏-邱永臣+

一个关于设计开源API网关系统的设想

在几年的工作过程中,我经历了多个开放平台型系统,系统中存在些许不如意的瑕疵,而出于稳定考虑,大部分尽可能保持原样不再迭代改进,我的很多想法没法付诸实现,所以渐渐萌生了一个想法:设计开发一套全新的API网关,在开发过程中随时推翻原先的设计,只求能试验我的设想,同时将其开源,供其它同志参考学习。

API网关中很重要的一部分是协议转换,而大部分已开源的API网关几乎都是http->http,很少有大型互联网公司开源自己的http->rpc,更不用说”多协议->多协议”。

协议转换是最基础的功能性需求,其它的功能性需求有限流、熔断、黑白名单、日志、验签、授权、文档、SDK、调试台等。在实现基本功能的基础上,可以针对高可用、高性能进一步优化,比如全链路异步、隔离、多级缓存。

HTTP/2与HTTPS协议的原理

一、前言

早先,咱们的吃瓜网站部署在局域网里,通过谷歌代理穿透内网的方式对外提供服务,那时网站速度极慢,10秒内有响应算正常。毕竟浏览器的请求先到达美国洛杉矶,再绕道回中国大陆,经过联通线路抵达局域网,速度慢是肯定的。

后来,我们启用CDN,让主域名指向阿里CDN,源域名仍是通过穿透指向局域网。此时,热点的url速度较快,而冷门url的响应速度和以前一样慢。
再后来,为了解决冷门url的问题,网站从局域网搬迁至阿里云,此时网站总体响应速度提升至2~3秒。

再后来,CDN提供HTTP/2的能力,所以咱们立马申请一个免费SSL证书,强制HTTPS之后接着启用HTTP/2。开启HTTP/2以后,网站响应速度从几秒缩减至几百毫秒。(注:后来网站中加载大量第三方的插件,整体速度慢下来,此事略开不讲)

有好奇好问的同学说了:”那你这个HTTP/2有什么神奇的地方,速度怎么提升的?”咱们这一节就来探究该问题。

Read More

Spring技术内幕总结

零、前言

相信绝大部分Java攻城狮都用过Spring框架吧,我在这里总结下Spring的几个要点。

最关键最核心的部分是IOC容器AOP框架(不信出去面试一圈你会发现所有面试官都会问你这2点内容哦),对于IOC容器,我们只需理解BeanFactory接口和ApplicationContext接口,差不多便能掌握其原理,比如要定位Resource、载入BeanDefinition、存入Map仓库、依赖注入时通过反射设置变量值等等;对于AOP框架,我们只需记住它是代理模式的包装,是简单易上手的代理。

在此基础上,深入SpringMVC的源码阅读一番,弄懂IOC容器的启动过程与SpringMVC的启动过程,DispatcherServlet在处理一个http request时如何定位Handler、如何渲染结果,这样也能掌握SpringMVC的原理(如果有同学侧重于http网络方面的开发,应该会对SpringMVC如何处理request/response感兴趣)。

Read More

从0到1编写一个RPC框架(基于Zookeeper)

零、前言

这是我很久之前造的一个RPC轮子,名叫AirRPC,它基于zookeeper,和阿里dubbo、美团pigeon等框架比较类似(毕竟RPC框架原理都一样)。源码在github上,有兴趣的同学可以看看:https://github.com/qiuyongchen/AirRPC

下面将详细描述出整个项目的设计思路与实现,包括相关的理论与模型、框架建模与框架模块设计、部署步骤与测试结果等。

一、引言

1.1 研究背景和意义

团队在发展初期,由于规模和业务量小,网站开发人员只需将网站以Tomcat + Linux + MySQL + Java的形式部署在一台机器上便足以应对业务流量。

随着时间发展,团队内的业务日益复杂,仅依靠一台机器已不能应付流量压力,此时为了及时跟进业务的发展,网站开发人员通过使用分而治之的手段,把整个网站业务进行垂直拆分。比如,可以根据网站的业务的不同,把一个项目分拆成多个,每个项目专人专职,由专门的开发人员负责,各个业务的流量压力由不同的项目承担,这在一定程度上可以缓解业务发展带来的压力。

久而久之,各个项目的开发人员发现,各一个项目都需要执行许多相同的业务操作,比如用户管理,产品管理和供应商的管理等,而且,每个项目都要和数据库保持连接,给数据库带来了极大压力,数据库有拒绝服务的可能性。为了解决该问题,开发人员提出了水平切分,也就是分布式服务的解决方案,将多个项目共同拥有的业务操作提取出来,根据业务类型放到多个Service项目中,各个非Service项目均调用Service项目提供的服务。

本项目正是一个致力于解决水平切分问题的分布式服务框架,让小型开发团队可以透明地从单机服务架构扩展到分布式服务架构。

Read More

Kafka原理深入总结

零、前言

Kafka是一个流处理平台(在java业务世界中被当成消息队列),性能非常不错,在高并发方面,kafka利用分区技术实现多路消费并发;在高可靠方面,主要核心是复制与分区副本。

我在笔记中记录了kafka的相关概念,比如broker、生产者、消费者、副本、分区、分区首领、分区副本等,也记录了kafka的存储原理,比如分区文件、系统页缓存、零复制等。

提到MQ,Java程序员多少都会使用到,了解其底层原理还是可以的。

一、脑图笔记

Read More

Zookeeper与Zab协议深入总结

零、Zookeeper

Zookeeper之有名,已不需再说,大量中间件基于zk来做分布式一致性、master选举、注册订阅服务。它的核心功能是主从绝对一致,且拥有发布/订阅能力,并拥有顺序性、原子性和单一视图等特性,着实好用(实际上吃瓜群众邱永臣在造RPC轮子时,也是将zk作为注册中心)。

一、Zab协议

Zookeeper的核心是Zab协议,即zookeeper的原子广播协议。Zab主要靠2个模式来保证一致性,分别是恢复模式(选leader)和广播模式 。

恢复模式:在集群启动之初,或是leader挂掉之后,各个服务器开始选出新leader,并更新年号纪元(要点是选zxid最大的服务器)。恢复过程中,为了保证一致性需要解决两个问题,一个是旧leader已经commit的提议必须应用到所有follower,另一个是仅有旧leader提出的提议必须回滚,解决上述俩问题的要点也是选zxid最大的服务器作为新leader。

广播模式:leader在应用事务请求之前,必须取得超半数follower的同意,过程及其类似两阶段提交。和两阶段不同的是,leader发出提议后,follower需记录在事务日志中,写磁盘成功后返回ack,leader得到超半数ack后,统一commit(因为follower有队列实现事务串行且有事务日志,所以commit大概率成功);另外,Zab没有rollback选项,若follower不同意leader的提议,该follower被踢出投票席(所以只能ack),需重新同步leader数据。

二、脑图笔记

可以下载PDF脑图细看(其中包括单机事务和分布式事务的研究):Zookeeper与Zab协议深入总结脑图

Redis深入总结

零、前言
这份总结中记录redis几大数据结构的实现(包括链表、字典、跳跃表、压缩列表和整数集合),在对象上redis用压缩列表存储list/hash/sortedset而用跳跃表和字典实现sorteset,令人印象深刻;同时记录了redis的RDB和AOF持久化方案、复制特性和谣言算法实现集群化;最后对redis的事务、事件等功能也进行了一番描述。

一、脑图笔记
由于脑图长宽过大,转成jpg图片之后较难打开,所以我把它转成了PDF文件,可以点击链接进行下载:redis深入总结PDF脑图