编程书籍

作者:郑昌顺链接:https://www.zhihu.com/question/50408698/answer/1489486317来源:知乎著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。 我们邀请到微软亚洲研究院首席研发经理邹欣来推荐IT行业的书。他在工作之余,出版了几本书,其中《编程之美》《构建之法》在程序员界颇具名气。此外,他还是拥有30余万粉丝的微博大V。他推荐的好些书已经“上了年纪”,但他认为“优秀的书出现好些年了,只不过我们还没好好读”。这份书单中的也并非都是专业门槛很高的书籍,有的也适合各个领域的读者阅读,希望大家能喜欢。 我今天想通过三个公式,向大家介绍IT行业中一些有趣的书。 第一个公式:程序 = 数据结构 + 算法 Algorithms + Data Structures = Programs中文版:《算法+数据结构 = 程序》作者:Niklaus Wirth 推荐理由:《算法 +

Read more

远东

说到远东,伏拉迪沃斯托克和哈巴罗夫斯克都不算太“东”,最东的主要居住地是堪察加半岛的彼得罗巴普洛夫斯克堪察加边疆区(因为楚科奇半岛没有大型人类生活区),在我看来倒是一个非常美丽宁静的地方,除了地震多了点外,其他都还好。 有天夜里1点多地震,真是把我快吓尿了… 虽然只有5.7级,但是老房子晃动的厉害,总之那会真有点怕了。这是地震那天在日本的同事告诉我的,由于这网络不好,查不到震中,差点急死,还得求助新浪微博。。。 好吧,言归正传,多的字我就不打了,通过几张照片来看看吧。 首先为了让大家知道堪察加在哪,我先画个地图。。。红点的地方就是我住的地方,全称是彼得罗巴普洛夫斯克堪察加边疆区。。。 吃什么呢?三文鱼便宜的根不要钱似的。。。 炸一炸,或者做鱼汤。。。 帝王蟹280人民币,卢布跌了以后现在不到200块了。。。 上等鱼子酱就不说了 机场破了点,你没看错,这就是机场出口。。。 城市还可以,坡多了一点。。。 家门口的超市,超市物价很便宜,吃餐馆消费水平和北京上海差不多。 远东人民的涂鸦水平还是可以的… 这是我第一个房东家,有个很可爱的小女儿,和一只很肥的猫。。。其实和国内比较像。 我第二个房东家养了50多只雪橇犬,还有三个熊孩子。。。就是前面吃帝王蟹那三个。 对了,我们没事爬火山玩。忘了说,这有将近300座火山,29座是活火山,其中19座是世界自然遗产。 或者坐皮艇去飞钓,钓三文鱼,晚上回去做鱼汤,多的鱼肉喂雪橇犬。 傍晚就去拍日落 周末一般大家都出去家庭野营,打打猎什么的 城里面有半年时间能看到海狮。。。

Read more

Flink基础理论

文章目录 Flink概述 Flink生态 为什么选择Flink? 系统架构 JobManager 运行架构 常用的类型和操作 程序结构介绍 并行数据流 Task and Operator Chains 核心原理 Window&Time Window Time State状态管理 按组织形式的划分

Read more

API GATEWAY

前言 假设你正在开发一个电商网站,那么这里会涉及到很多后端的微服务,比如会员、商品、推荐服务等等。 那么这里就会遇到一个问题,APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话,可以给每个业务都分配一个独立的域名(https://service.api.company.com),但这种方式会有几个问题: 每个业务都会需要鉴权、限流、权限校验等逻辑,如果每个业务都各自为战,自己造轮子实现一遍,会很蛋疼,完全可以抽出来,放到一个统一的地方去做。 如果业务量比较简单的话,这种方式前期不会有什么问题,但随着业务越来越复杂,比如淘宝、亚马逊打开一个页面可能会涉及到数百个微服务协同工作,如果每一个微服务都分配一个域名的话,一方面客户端代码会很难维护,涉及到数百个域名,另一方面是连接数的瓶颈,想象一下你打开一个APP,通过抓包发现涉及到了数百个远程调用,这在移动端下会显得非常低效。 每上线一个新的服务,都需要运维参与,申请域名、配置Nginx等,当上线、下线服务器时,同样也需要运维参与,另外采用域名这种方式,对于环境的隔离也不太友好,调用者需要自己根据域名自己进行判断。 另外还有一个问题,后端每个微服务可能是由不同语言编写的、采用了不同的协议,比如HTTP、Dubbo、GRPC等,但是你不可能要求客户端去适配这么多种协议,这是一项非常有挑战的工作,项目会变的非常复杂且很难维护。 后期如果需要对微服务进行重构的话,也会变的非常麻烦,需要客户端配合你一起进行改造,比如商品服务,随着业务变的越来越复杂,后期需要进行拆分成多个微服务,这个时候对外提供的服务也需要拆分成多个,同时需要客户端配合你进行改造,非常蛋疼。 API Gateway 更好的方式是采用API网关,实现一个API网关接管所有的入口流量,类似Nginx的作用,将所有用户的请求转发给后端的服务器,但网关做的不仅仅只是简单的转发,也会针对流量做一些扩展,比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等,这样将通用的逻辑抽出来,由网关统一去做,业务方也能够更专注于业务逻辑,提升迭代的效率。通过引入API网关,客户端只需要与API网关交互,而不用与各个业务方的接口分别通讯,但多引入一个组件就多引入了一个潜在的故障点,因此要实现一个高性能、稳定的网关,也会涉及到很多点。 API注册 业务方如何接入网关?一般来说有几种方式。 第一种采用插件扫描业务方的API,比如Spring MVC的注解,并结合Swagger的注解,从而实现参数校验、文档&&SDK生成等功能,扫描完成之后,需要上报到网关的存储服务。 手动录入。比如接口的路径、请求参数、响应参数、调用方式等信息,但这种方式相对来说会麻烦一些,如果参数过多的话,前期录入会很费时费力。 配置文件导入。比如通过Swagger\OpenAPI等,比如阿里云的网关: 协议转换 内部的API可能是由很多种不同的协议实现的,比如HTTP、Dubbo、GRPC等,但对于用户来说其中很多都不是很友好,或者根本没法对外暴露,比如Dubbo服务,因此需要在网关层做一次协议转换,将用户的HTTP协议请求,在网关层转换成底层对应的协议,比如HTTP

Read more