您的位置:首页 > 其它

我能够快速读书的秘密:主要靠“猜”!

2019-12-11 08:50 901 查看

有很多人问我,平时是怎么看技术书的,我今天拿一个案例来讲一下,你会看到,我主要靠“猜”,自己想想解决方案,然后到书中去验证。干货内容较多,建议静心慢慢看。

1



我知道Docker是怎么回事,但是不太清楚Kubernetes究竟在干什么,它要解决什么问题?有哪些功能?在网上搜索了一些文章,可是都无法让我满意,因为他们都是非常宏观地讲一讲,然后马上就进入使用细节,让人还是云里雾里。 


之前我就说过,想深入地了解一门技术,最好的办法就是看书,于是就去购书中心转了一圈,发现一本书籍《Kubernetes in Action》,翻了一会儿我就觉得这本书不错,就拿它来学习吧。 


 (这里插入一句,我的公众号文章只能讲述一个技术的本质问题,给大家一个大局观,具体的细节还得去读相关的书,有些人抱怨说通过我的文章学不会一个技术,那真是冤枉我了。) 



2




这本书一开始就提到了微服务,这是个非常好的切入点,我脑海中立刻想到了微服务的特点,可以独立部署,轻松扩容。


那扩容的时候具体该怎么做呢?例如有个订单服务,我想把部署10份,难道我跑到服务器端,手工启动10个实例?


这肯定不符合自动化运维的方式,也许可以写个脚本,接受一个参数或者读取配置文件,把实例自动创建起来。 


但是仔细一想,这样是不行的,因为现实中会有很多服务器,脚本怎么去管理呢?脚本怎么获取它们的IP以及它们的负载情况,然后把Docker实例分发创建到合适的服务器中呢? 


于是第一个猜测来了:


最好是有个系统,它能管理所有的服务器,我只要告诉他,把订单服务的docker镜像部署10份,剩下的事情就不用我管了,都由这个系统来搞定。


这时候我隐隐约约地感觉到了Kubernetes的核心功能。 


于是我跳过了微服务的介绍,Docker的介绍,这些都是老掉牙的东西了,迅速翻到了第16页:



这幅图画得相当棒,清楚地展示了K8s的核心功能,但是仔细看以后,就发现有两个微服务被放到了一起,作为一个整体来部署,这是我之前没有想到的! 


部署的最小粒度并不是Docker镜像,而是另外一个东西从系统设计的角度来看,必须得有个词来表达,这个东西是什么? 


于是我又往后翻,哦,原来这个词叫做pod。 


作者告诉我在第3章有详细介绍,我迫不及待地往后翻,试图满足好奇心:pod到底是什么东西。 


原来这些pod就像局域网中的一个个独立的逻辑主机啊,每个Docker实例都是一个进程。 




3



到目前为止,我就明白了k8s本质上是一层抽象,这一层抽象屏蔽了服务器的细节,程序员不需要知道程序运行在哪个服务器上,只需要告诉k8s自己的需求就好。 


那用什么方式来告诉k8s呢?这很容易猜测到,可以: 


1. 通过命令行参数传递给k8s, 但是参数太受限。 


2. 用配置文件,在其中可以指明pod的名称,docker的镜像名称......  可以用XML格式, JSON格式,YAML格式.....  


当然,这些念头都是一闪而过,我翻开这本书的第3章,主要讲pod,果然是用YAML,JSON去创建pod, 由于已经预料到了,没什么新意,稍微看了看就跳过。 


让我没有想到的是可以使用标签命名空间对pod进行分组,但是讲解有点啰嗦,似乎也不是核心概念,稍微翻了一下就过去了。 


稍等 !为什么不在创建pod的时候指定pod的数量啊?比如我想创建10个订单服务的docker实例,在哪里指定?仔细看看那些YAML文件,确实没有副本数量,这k8s搞什么鬼?这里没有指定,肯定在别的地方,那就是说:


除了pod之外,还有一个概念,用来指定pod和副本之间的关系,这个概念是什么?



4



快速翻到第4章,哈哈,原来这个概念叫做ReplicationController(简称RC),由它来保证pod的数目符合要求,多了就删除,少了就添加。 



从设计角度来看,再次体现了关注点分离pod负责“静态描述”,像一个模板,就像class, RC负责运行时管理,来产生pod的object。 


创建RC也是使用YAML,比较让我意外的是,在指定pod时,用了前面所讲的标签,看来标签是组织pod的重要方法,有时间回去看看细节。 


需要注意的是,在管理pod数目的时候,用的是声明式:“我想要运行10个订单实例”, 而不是“我想增加3个订单实例”或“我想删除3个订单实例”。 你不用告诉k8s做什么、如何做,只是指定期望的状态就好。 


5



如果你也善于思考的话,这时候就会冒出了一个新问题: 


这些pod 不断地被删除,被增加,不断地变化,那外界怎么去访问他们呢? 


比如客户端正在访问pod1,然后pod1所在的机器挂掉,ReplicationController在另外一台机器上创建了pod2,IP都变了,那客户端下一次去访问pod2呢? 


如果让我设计,我肯定得提供另外一个抽象层,让这个抽象层来屏蔽后端的变化,让客户端连接到这个抽象层上。 


k8s 会怎么做呢?第4章给出了答案:服务。  我个人觉得这个词起得不好,太抽象,太广泛。 



可以看出,k8s和其他系统一样,也是不断地通过分离关注点,不断地抽象来解决一个个问题的


到目前为止,我脑海中想的都是那些“无状态”的pod,可以随意增加和删除, 但肯定存在“有状态”的pod,有持久化的需求,可以把数据存储到硬盘上,这该怎么办? 


带着这个问题,继续上路吧! 



6




好了,啰嗦了这么多,稍微总结一下:我希望给大家分享的就是,看书的时候要主动思考,不要被动接受


带着问题去看,自己先想想解决方案,然后到书中去验证,效率会非常高,读起来会非常快。


如果自己的问题在书中很快就得到回答,那读起来就会酣畅淋漓;如果迟迟得不到回答,或者书中一直不厌其烦地描述细枝末节,那我很快就丧失兴趣,把书扔掉。 


当然,由于每个人的基础不同,可能刚开始读书的时候提不出问题,或者提不出有价值的问题,这时候可以去直接看具体内容,但是不能放弃思考:这个技术点是要解决什么问题的?是怎么解决的?


希望每个人都建立一套自己的知识体系,从这个知识体系中能伸出很多的触角,能像海绵一样吸收外界的知识,不断地为自己的知识体系添砖加瓦。


关于作者:刘欣码农翻身公众号作者,畅销书《码农翻身》作者,15年以上开发经验,前 IBM 架构师,领导过多个企业应用架构设计和开发工作;洞察技术本质,用故事讲解技术是拿手好戏。


往期精彩回顾
我是一个线程

我是一个Java Class

面向对象圣经

函数式编程圣经

TCP/IP之大明邮差

CPU阿甘

我是一个网卡

我是一个路由器

一个故事讲完HTTPs

编程语言的巅峰

Java:一个帝国的诞生

JavaScript:一个屌丝的逆袭

负载均衡的原理

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐