(简评)Kubernetes In Action(大势所趋)

(简评)Kubernetes In Action(大势所趋)

如果你看了“简评Specifying Systems:关于行为时序逻辑”这篇文章,下载了那本书开始阅读,并开始怀疑自己的智商的话,那么我推荐你开始阅读这本书。劳逸结合,找回自信。 ( ̄∇ ̄) ( ^ω^ )


Kubernetes+docker是我必须要安利且强烈安利的一项技术。类似的技术在未来将会作为基础构架,成为程序员,特别是互联网行业的程序员的必备技能(就好比现在的程序员需要知道内存,硬盘和网络一样); 这同时会影响程序员做系统设计的环境,以至于反过来影响“什么是好的设计”这件事本身。

待我细细道来。


系统设计的演化

如果你还看了(简评)建造可进化的系统构架所安利的这本书的话,你就应该知道architecture的best practice正从SOA走向microservices。


原因无他,逐利的资本而已。


当软件和硬件一样贵,甚至比硬件还贵的时候,具有license的第三方软件(包括操作系统)是企业的珍贵资源,会影响所有这个企业内的任何system design。另一方面,当时大家对软件的认识类似于建筑工程,所以才会有software architect,architecture这种概念,即:软件一旦实现完成,会很难做大修改,所以一方面在waterfall的年代,纸上设计设计半年一年那都是很正常的事情,另一方面超高的软件搭建修改cost加重了领导层对“重用已经实现的软件”的要求,这种要求又反过来加重了需要high cost的“heavy design"的企业文化, 最终成为恶性循环。一个系统的architecture要以珍贵的软硬件为核心,长远的软硬件规划眼光为指导。使得最大的程度能够复用购买的,和自我产出的写好的软件成为第一目标, 而应对持续变化的业务则是软件需求的2等公民,所以,你有一个需求可能可以挣20w,OK,我们改软件买license来支持这个需求需要花200w,需求再见.
逐利的资本还决定了其他很多事情,在那个年代,你说你的软件需要跑2份甚至多份待机,来保证主程序死了,立刻有备用程序接替,从而实现high availability。 大家会说你疯了(长期跑这么多软件的license钱,远多于停止对client服务几个小时的cost);灵活的scale up和down,抱歉不可能,买多少license和机器是提前一年计划好放在预算里的…
不过好在当时能用软件解决问题的公司已经是对其他公司降维打击了,所以无法灵活应对市场需求也不是什么大问题…

直到开源免费的软件和操作系统的出现,改变了这一切,软件不再昂贵了。Agile的发展,continuous delivery,devOps,高级云服务,软件设计思路的日益成熟,行业的经验的进步,人才的涌入, 培养与积累… 所有这些都进一步降低了“更改软件”的cost。而云服务商的大批出现,使得就连硬件也已经可以临时购买,不用的时候就release掉,像自来水一样,按需使用。

这样,在大家都还没注意的时候,商业需求开始在系统设计中变成特等公民。

(这也是为什么DDD在提出了快小20年,然而近期才火热起来的原因)

所有的行业和公司都在信息化,当有一些公司开始“Domain Driven”,用自己的强技术实力使得软件更改的cost无限低(Domain Driven相比Tech Driven恰恰不是对tech的要求低了,而是更高了),从而可以更灵活的无限迎合商业需求,这些公司就开始对传统软件公司进行降维打击。当人们会因为一个小功能就喜欢上一个软件而抛弃不好用的另外一个软件的时候。能否快速支持“商业需求”,甚至用科学的方法,用软件构架快速安全的实验来探索/培养/发展“客户需求”(用时髦的话来说就是构建和发展生态)开始成为决定企业生死的重中之重;自我挑战,在新的竞争者出现之前,用新的自己杀死老的自己,是Google, 微软,Amazon, Facebook,阿里腾讯等各大巨头霸占自己领域,利用自己的数据,自己的人才储备,达到“我快所以我更会快”,“我大所以我会更大”的飞轮效应之不宣秘笈。
当软件不再为公司的硬件环境束缚, 当集中式的,复用第一的设计理念开始崩溃; 强调灵敏应对变化,不同组件可以选择不同语言/数据库/构架,细粒度更改,让不同的组件选择自己需要的scalability,自动化测试部署,同部件多版本实验,甚至让部件可以一试即弃的微服务构架慢慢成为主流。分散,灵活,解耦,隔离成为设计文档中最火的关键字。


微服务和容器化带来的挑战

当系统组件越来越小,新的从未需要思考的问题开始出现。从只有一台大机器部署所有东西,组件全在一个进程或者jvm里,不需要考虑patial failure的世界里走出来,你需要面对很多新的问题和挑战: 我的service,程序,应该部署在那里?我用的一个文件不小心和另外一个程序重名,而他们恰巧部署在一台机器怎么办?不小心把过多的东西部署在了一台机器上怎么办?一台不知道部署了什么的机器突然挂了怎么办?我service部署好了,我的其他组件怎么能找到它?把需要相互通信的机器的ip机器名都配置好了,突然要增加机器或者减少机器,或者更换机器怎么办?service正在服务我想要更新程序怎么办?我rollout了一个bug结果所有的node上的服务都挂了怎么办?….

微服务的architecture比之前集中式的设计难上n多个档次,很多原先进程中的deterministic 同步方法调用,都将会被替换成跨service的远程调用。而分布式系统是non-deterministic的。这就好比给你一种cpu,它有99.99%的概率1+1返回2,而0.01%的概率1+1返回一个随机数. 在只有这种cpu的情况下,我需要你以100%的稳定性实现你原来的系统。。。

If you can’t build a monolith, what makes you think microservices are the answer? —Simon Brown




Container Orchestrators来帮忙

我们发现在微服务环境中,有很多共有问题是可以统一解决的。它们包括:

  • Service discovery: 让你的程序轻松获得任何其他组件的logical地址,即使这个组件真实的运行node换了100遍。
  • Scaling up/down: 自动根据负载增加和减少机器,互联网公司最最基本需求
  • Load balancing:负载均衡自动均衡到不同的机器
  • Self healing: 组件由于任何原因(比如网断了,机器挂了)挂了都没问题,自动在另外的机器来启动。
  • Leader election
  • Security 等

而Container Orchestrators则提供了抽象和方便的工具来让程序员更简单和轻松的应对微服务构架下,我们遇到的各种难题。这就好比当多核成为趋势,多线程编程就成为程序员基本素质一样。而当我们的时代前进到这里, Container Orchestrators终将成为另外一种基础知识成为程序员的必备技能。所以即使你不喜欢Kubernetes,那么你也必然需要另一种类似的东西来解决Orchestration的问题;而解法都是类似的。

Kubernetes In Action

Kubernetes是Google开源的目前最成功的Container Orchestrators, 它可以提供上文中所提到的各种新“基础服务”,向application隐藏infrastructure,隐藏硬件事实。使得程序员只需要声明deployment和管理的“想达到的效果”,而不用自己去思考deployment和operation的细节。
有了Kubernetes 的帮助,普普通通的SDE-II甚至SDE-I都将可以较轻松的应对复杂混乱的分布式环境开发。
而Kubernetes In Action是一本非常非常对初学者友好的书,里边提供了非常有代入感的非常细致的例子和各种操作的范例,内容也比较详尽。而这些例子都是真真实实大型互联网公司中建造和维护service所遇到的核心问题和应对的best practise。比如Readiness Probe,liveness Probe, Blue/Green deployment, rolling rollout, Load Balance, auto-scaling...

最重要的,这本书还深入浅出的讲解了Kubernetes的构架和设计理念,非常难能可贵。你将能学到Kubernetes如何使用Action as Data(在文中你看不到这个词,我发明的…)这个思路,使得在non-deterministic的分布式环境中,为scheduler和controller这种需要“唯一决策者设计”的组件提供high availability的同时,使cluster的调度决策稳定可靠的方法(有点类似Akka的singleton actor, 但我们知道singleton actor是无法自动node failure tolerance的,即使Kubernetes提供的stateful replica也是无法自动node failure tolerance,那么差别在哪呢? 看了就知道啦~)。


缺点: 详实的例子,具体到细节的讲解对初学者是大大的加分项,但是对于对分布式系统和搭建high availability和scalability service已经很了解的读者来说,都是需要过滤的废话。。。这本书对我有用的地方加起来不会超过60页,然而我得翻完500多页把它们找出来。。。于是这本书将尽%90的部分被我mark成了这样。。。。



(完)



====== 小尾巴 =====

我是阿莱克西斯,10+年关于高并发,大数据处理的技术经验,常年与内部科学家合作,负责搭建预测优化后端黑魔法系统的Amazon Sr. SDE; 每天看技术书和paper到夜里1点的读书狂魔兼猫奴。

关注我,关注我的读书专栏,和解释分布式系统paper的专栏,带你成为程序艺术家,学习在战略分析层面的大道编程,讨论如何以构架师和技术负责人的角度看问题,玩转分布式系统~ 我们一起读书一起成长~

用谁都能看懂的方法解释分布式系统

一个书魔程序员的读书简评

编程到底难在哪里?www.zhihu.com

在做程序员的道路上,你掌握了什么概念或技术使你感觉自我提升突飞猛进?www.zhihu.com

请问分布式事务一致性与raft或paxos协议解决的一致性问题是同一回事吗?www.zhihu.com


编辑于 2018-10-23

文章被以下专栏收录

    我是阿莱克西斯,10+年关于高并发,大数据处理的技术经验,常年与内部科学家合作,负责搭建预测优化后端黑魔法系统的Amazon Sr. SDE; 每天看技术书和paper到夜里1点的读书狂魔兼猫奴。 关注我,关注我的读书专栏,和解释分布式系统paper的专栏,带你成为程序艺术家,玩转分布式系统~ 我们一起读书一起成长~