/images/avatar.png

为什么 JSON 需要转义

为什么 JSON 需要转义? [TOC] 适合人群:入门级 JSON 和 JSON 转义 21 世纪初,Douglas Crockford 寻找一种简便的数据交换格式,能够在服务器之间交换数据。当时通用的数据交换语言是 XML,但是 Douglas Crockford 觉得 XML 的生成和解析都太麻烦,所以他提出了一种简化格式,也就是 JSON。 JSON 其结构形如 {"云原生":"Kubernetes"},可以很直观的使用字符串表示对象或数据结构。对象或数据结构使用序列化接口转换成 JSON 字符串,比如 Golang 中的json.Marshal接口。 你可能会有这样的疑问:既然 JSON 字符串结构简单,为什么不直接使用字符串拼接的方式,而是要使用 JSON 序列化接口呢? 结果显而易见:JSON 序列化接口会一并将数据中的特殊字符进行转义,防止其破坏 JSON 原有结构。比如数据中含有双引号"特殊字符,序列化接口便会对双引号进行转义,最终结果类似于{"云原生":"\"Kubernetes\""},否则,该场景下直接拼接的字符串会非法。 JSON 转义 许多程序设计语言把双引号字符(")用作字符串的分界符。反斜线(\)转义字符提供了两种方式来把双引号字符置入字符串中,或者是使用转义序列\"表示单个的"字符本身,而不是作为字符串分界符;或者是直接开始字符"的 16 进制编码值的转义序列\x22来表示",也可以使用 8 进制编码值的转义序列,如\042。 在 Python 中,下面的代码将会产生语法错误 1 print "Cloud Navite "Hello World!"."; 而另一段 Python 代码则会产生符合预期的结果 1 print "Cloud Navite \"Hello World!\"."; 在 JSON 中,也是如此:当使用 json 接口解析字符串{"云原生":""Kubernetes""}时会报错,而解析经过转义的 JSON 字符串{"云原生":"\"Kubernetes\""}则会解析成功。

《欧洲绘画五百年》参观有感

生日的时候飞去成都参观成都博物馆正在展出的西方绘画史,庆祝生日,感慨良多,记录下自己的感想 画作主题受限于思想。被神学/基督教控制的文艺复兴初期,画作只能是神祗,颜料也尽显奢华;随着西方文艺复兴给人们带来的思想解放,大家的主题不再局限于神祗,更注重于人本身,比如充满情趣的田园画,肖像画/自画像;随着科技进步,颜料可以带出门,派生出风景画派;大家生活水平提升,画画不再是一定是谋生手段(为达官贵人画肖像画可以填饱肚子),可以画自己想画的东西,主题百花齐放。 吃饱了才能搞艺术。西方文艺复兴以来其艺术中心的变迁:意大利/罗马(文艺复兴)->荷兰黄金时代(荷兰小画派)->巴黎->西欧以及美国百花齐放百家争鸣,其实也对应的是西方十四世纪以来的经济中心的变迁:从东西罗马纵横捭阖,荷兰/西班牙黄金一代/大航海时代,法兰西帝国和日不落帝国,第一次和第二次工业革命英国和美国变为世界的两极。 一个人的成功不仅要靠自身的努力和天分,还要考虑历史的进程以及找对师父。要有天分,很多大家早在十几岁二十几岁其绘画天赋便锋芒毕露;要靠个人努力,大部分在展上的画师无一不是耗费了巨大的精力投入在艺术创作中,年少成名的画师也是十一二岁便要在画师家里当学徒,兢兢业业;要站在巨人的肩膀上,要师从名师/大家,名画家的师父往往也很有名,自学成才的很少,比如高更(月亮与六便士的主角)。 画作充满美感。个人艺术细胞不足,对于艺术性的感受就是,不论是端庄严谨的教会画、轻松愉快的田园画、栩栩如生的肖像画和风景画、百花齐放百家争鸣的现实主义、浪漫主义、象征主义画作,都很美。在场看跟在网上或书上看的感觉完全不一样。 参考链接 欧洲绘画五百年丨高更:被画画拐上“歧路”,却抵达了艺术的神坛

从 nginx 热更新聊一聊 Golang 中的热更新

从 nginx 热更新聊一聊 Golang 中的热更新 静态语言在服务器编程时都会遇到这样的问题:如何保证已有的连接服务不中断同时又升级版本? 最近花了点时间看了下 nginx 热更新代码流程,想了下结合之前的经验一并总结下热更新 热更新是什么? 举个例子,你现在在坐卡车,卡车开到了 150KM/H 然后,有个轮胎,爆了 然后,司机说,你就直接换吧,我不停车。你小心点换 嗯。就这个意思 网关中的热更新 服务程序热更新这个问题在层 7 网关中尤其严重,网关中承载着大量的请求,包括 HTTP/HTTPS 短连接、HTTP/HTTPS 长连接、甚至是 websocket 这种超长连接(websocket 通常连接时间会很长,十几分钟到几天不等)。服务进程热更新是非常有必要的。 网关作为一个基础组件,需要保证高可用,是很难将其先停下来再更新的; 有人说可以使用负载均衡将需要更新的组件先隔离,再停机更新,但是如果是一个很小的集群没有负载均衡呢,又或者这样手动一台一台升级也着实麻烦,部分情况下就算隔离了也不过是不会有新的连接过来,旧的连接/请求依旧需要处理完成,否则就会造成部分服务不可用 不过实际上线上操作是集群隔离加热更新一起操作 nginx 热更新 (Upgrading Executable on the Fly) nginx [engine x] 是 Igor Sysoev 编写的一个 HTTP 和反向代理服务器,另外它也可以作为邮件代理服务器。 它已经在众多流量很大的俄罗斯网站上使用了很长时间,这些网站包括 Yandex、Mail.Ru、VKontakte,以及 Rambler。据 Netcraft 统计,在 2012 年 8 月份,世界上最繁忙的网站中有 11.48%使用 Nginx 作为其服务器或者代理服务器。 NginX 采用 Master/Worker 的多进程模型,Master 进程负责整个 NginX 进程的管理。Nginx 的模块化、热更新、Http 处理流程、日志等机制都非常经典。这里将会简要介绍一下热更新的机制

获取服务器本机 IP 的不同语言实现

C/C++ 版本 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 int CNetOperations::GetLocalIp(__be32 *pLocalIp, const char* pIfName) { if (!pLocalIp || !pIfName) { return (-EINVAL); } int iSocket; iSocket = socket(AF_INET, SOCK_DGRAM, 0); if (iSocket < 0) { return (-errno); } struct ifreq stIfr; memset(stIfr.ifr_name, 0x0, sizeof(stIfr.ifr_name)); strcpy(stIfr.

perf 入门教程(待补充和完善)

perf 使用教程 perf 简介 Perf 是 Linux kernel 中的系统性能优化工具,perf 基本原理的话是在 CPU 的 PMU register 中 Get/Set performance counters 来获得诸如 instructions executed,cache-missed suffered,branches mispredicted 等信息。 perf 本身的工具有很多,这里主要介绍个人在查询程序性能问题时使用的一些工具 包括 perf list、perf stat、perf record、perf report perf list 使用 perf 之前肯定要知道 perf 能监控哪些性能指标吧?那么就要使用 perf list 进行查看,通常使用的指标是 cpu-clock/task-clock 等,具体要根据需要来判断 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $ perf list List of pre-defined events (to be used in -e): cpu-cycles OR cycles [Hardware event] instructions [Hardware event] … cpu-clock [Software event] task-clock [Software event] context-switches OR cs [Software event] … ext4:ext4_allocate_inode [Tracepoint event] kmem:kmalloc [Tracepoint event] module:module_load [Tracepoint event] workqueue:workqueue_execution [Tracepoint event] sched:sched_{wakeup,switch} [Tracepoint event] syscalls:sys_{enter,exit}_epoll_wait [Tracepoint event] … 不同内核版本列出的结果不一样多。.

性能调优利器--火焰图

本文主要分享火焰图使用技巧,介绍 systemtap 的原理机制,如何使用火焰图快速定位性能问题原因,同时加深对 systemtap 的理解。 让我们回想一下,曾经作为编程新手的我们是如何调优程序的?通常是在没有数据的情况下依靠主观臆断来瞎蒙,稍微有些经验的同学则会对差异代码进行二分或者逐段调试。这种定位问题的方式不仅耗时耗力,而且还不具有通用性,当遇到其他类似的性能问题时,需要重复踩坑、填坑,那么如何避免这种情况呢? 俗语有云:“工欲善其事,必先利其器。”个人认为,程序员定位性能问题也需要一件“利器”。 如同医生给病人看病,需要依靠专业的医学工具(比如 X 光片、听诊器等)进行诊断,最后依据医学工具的检验结果快速精准地定位出病因所在。性能调优工具(比如 perf / gprof 等)之于性能调优就像 X 光之于病人一样,它可以一针见血地指出程序的性能瓶颈。 但是常用的性能调优工具 perf 等,在呈现内容上只能单一地列出调用栈或者非层次化的时间分布,不够直观。这里我推荐大家配合使用火焰图,它将 perf 等工具采集的数据呈现得更为直观。 初识火焰图 火焰图(Flame Graph)是由 Linux 性能优化大师 Brendan Gregg 发明的,和所有其他的 profiling 方法不同的是,火焰图以一个全局的视野来看待时间分布,它从底部往顶部,列出所有可能导致性能瓶颈的调用栈。 火焰图整个图形看起来就像一个跳动的火焰,这就是它名字的由来。 火焰图有以下特征(这里以 on-cpu 火焰图为例): 每一列代表一个调用栈,每一个格子代表一个函数; 纵轴展示了栈的深度,按照调用关系从下到上排列,最顶上格子代表采样时,正在占用 cpu 的函数; 横轴的意义是指:火焰图将采集的多个调用栈信息,通过按字母横向排序的方式将众多信息聚合在一起。需要注意的是它并不代表时间; 横轴格子的宽度代表其在采样中出现频率,所以一个格子的宽度越大,说明它是瓶颈原因的可能性就越大; 火焰图格子的颜色是随机的暖色调,方便区分各个调用信息; 其他的采样方式也可以使用火焰图, on-cpu 火焰图横轴是指 cpu 占用时间,off-cpu 火焰图横轴则代表阻塞时间; 采样可以是单线程、多线程、多进程甚至是多 host,进阶用法可以参考附录 进阶阅读; 火焰图类型 常见的火焰图类型有 On-CPU,Off-CPU,还有 Memory,Hot/Cold,Differential 等等。他们分别适合处理什么样的问题呢? 这里笔者主要使用到的是 On-CPU、Off-CPU 以及 Memory 火焰图,所以这里仅仅对这三种火焰图作比较,也欢迎大家补充和斧正。 火焰图分析技巧 纵轴代表调用栈的深度(栈桢数),用于表示函数间调用关系:下面的函数是上面函数的父函数; 横轴代表调用频次,一个格子的宽度越大,越说明其可能是瓶颈原因; 不同类型火焰图适合优化的场景不同,比如 on-cpu 火焰图适合分析 cpu 占用高的问题函数,off-cpu 火焰图适合解决阻塞和锁抢占问题; 无意义的事情:横向先后顺序是为了聚合,跟函数间依赖或调用关系无关;火焰图各种颜色是为方便区分,本身不具有特殊含义; 多练习:进行性能优化有意识的使用火焰图的方式进行性能调优(如果时间充裕); 如何绘制火焰图? 要生成火焰图,必须要有一个顺手的动态追踪工具,如果操作系统是 Linux 的话,那么通常通常是 perf 或者 systemtap 中的一种。其中 perf 相对更常用,多数 Linux 都包含了 perf 这个工具,可以直接使用;SystemTap 则功能更为强大,监控也更为灵活。网上关于如何使用 perf 绘制火焰图的文章非常多而且丰富,所以本文将以 SystemTap 为例。