获得徽章 7
年前收到的,今天刚开箱,有VIP会员卡、福袜、围巾、工卡套、一个小游戏... 😊😊😊 感谢掘金!今年还得再发几个大招[奋斗][奋斗][奋斗]
萤火架构于2023-01-29 10:21发布的图片
萤火架构于2023-01-29 10:21发布的图片
萤火架构于2023-01-29 10:21发布的图片
1
K8S中需要什么样的存储?👀我归纳为三种:

1. 容器自身:包括应用程序和它的运行环境。这部分存储空间跟随容器的生命周期,容器创建分配,容器释放则释放,这部分空间在节点本地分配。我们知道镜像是分层的,创建容器化实例时会采用一种联合文件系统的技术,让应用看起来就是在用一个文件系统。

2.依赖的外部数据:如配置、密钥、token和Pod的一些信息,它们需要在容器启动时挂载,实际上也是存储在本地节点,只不过它是某种机制同步到本地的。这在K8S中称为Projected Volume。

3.应用生产的数据:如业务系统中用户上传的文件,数据库程序中需要持久化的数据,还有一些可能是缓存数据。它们有的可以跟随容器的生命周期,比如缓存,容器重新调度后完全可以重建,有的则不可以,比如数据库数据,即使容器被重新调度,数据也得保持一致。为了更高的可靠性,这些存储空间需要更可靠的保障机制,避免数据丢失。这些数据大致可分为临时性和持久化两种,K8S中对应的是Ephemeral Volumes和Persistent Volumes。👍
展开
萤火架构于2022-09-23 09:38发布的图片
评论
K8S中为什么会有一个Ingress Class?

在k8s中管理外部流量的对象称为Ingress,它有一套标准的配置项,但是每家的需求又有不同,所以K8S把实现Ingress开放给了社区,也就是会有很多不同的Ingress Controller,用户需要在声明Ingress时指定对应的Controller,按说这样也就够了。但是后来K8S又搞出一个Ingress Class,现在需要在声明Ingress时指定Class,Class中在再声明Controller,你有没有想过为什么要加这么一层?

主要还是为了解耦,随着场景的拓展,很多Controller的自定义配置越来越多,都写在Ingress中很碍眼,不优雅,所以就有了Ingress Class,关于Controller的一切放到这里就好了。
展开
萤火架构于2022-09-22 14:43发布的图片
评论
Deno要做最快的JavaScript运行时了,你感觉它怎么样呢?
萤火架构于2022-08-16 11:27发布的图片
1
Consul、etcd、ZooKeepericon三者如何选择?直接提出这个问题有点耍流氓,因为没有描述任何应用场景和使用需求。不过这里还是可以对他们进行一些比较,说明其适应的场景,方便进行选择。

Consul覆盖了绝大部分服务发现的需求,开箱即用,还能实现跨云、跨集群的访问,在当前云原生的趋势下,Consul仍有很多用处,比如k8s上要实现跨集群访问就可以使用它。另外Consul也提供了一个键值存储,不过只支持字符串icon的格式,有时这是一个问题。

etcd的核心是一个键值存储,它对高并发的优化做得特别好,在不同流量的情况下表现十分稳定,k8s用它做底层的状态存储。它也可以做服务发现,不过需要搭配一些第三方工具。

ZooKeeper是一个老牌基础组件了,之前很多中间件都用它,它的核心也是键值存储,不过它还提供命名服务,分布式同步等一些功能。也可以用来做服务发现,还能用来做leader选举。不过ZooKeeper客户端要干的事相对多一点。

如果你要用键值存储,建议etcd。如果你刚开始做服务发现,建议试试Consul。如果你在k8s上,建议直接使用k8s的机制。
展开
萤火架构于2022-08-02 09:27发布的图片
萤火架构于2022-08-02 09:27发布的图片
萤火架构于2022-08-02 09:27发布的图片
萤火架构于2022-08-02 09:27发布的图片
萤火架构于2022-08-02 09:27发布的图片
萤火架构于2022-08-02 09:27发布的图片
评论
k8s中为什么会有pod这个概念?pod是k8s逻辑上调度的最小单元,有时候也称为原子单元,在此基础上k8s抽象了很多上层概念,比如Job、Development、Service等。我们经常听到容器化这个词,好像容器才是根本啊,那么k8s为什么不是以容器作为调度的最小单元呢?

首先从k8s的定义看,它是做容器编排和管理的,比如容器运行形态,是一次运行,还是长期驻守?运行前要准备什么?运行出错了怎么办?运行完毕后要干什么?这些事务是在容器原有功能之外的,如果要在容器上直接添加这些定义,那么各种容器运行时就要来支持它,这个还是有点麻烦的,所以k8s又虚拟了一层pod。这也是处理计算机问题的一种常见方法,增加一层,屏蔽掉底层的复杂性,让每一层专注自己的能力。

还有一种常见的说法,因为某个应用可能对别的应用有比较强的依赖,所以把它们组装在一起。这种依赖可能的表现形式有推送数据、拉取数据、代理等。这里举个例子,使用Consul做服务发现时每个部署节点都需要一个Consul Agent,这时候就需要把Consul Agent和应用程序封装在一个pod中。可能的场景还有日志采集、Web反向代理等。

可能有的同学会问,为什么不把多个应用放到同一个容器中?这个问题请看我之前的动态或文章。
展开
萤火架构于2022-08-01 09:31发布的图片
评论
为什么不建议在一个容器中放多个应用?容器没有限制放多个应用,但是这会让资源控制、生命周期管理会很困难,比如两个应用进程,它们分别可以使用的CPU和内存怎么限制?有一个进程死了,怎么监测并拉起来?还有另一个进程怎么办?当然技术上可以做到,但是一个容器只放一个应用显然更简单,而且每个镜像或者容器的意图更明确,不仅让应用之间的依赖解耦合,也方便不同人或团队之间的共享和复用这些镜像及其容器。
展开
萤火架构于2022-07-29 21:17发布的图片
评论
技术人如何知道自己是否在进步?有个简单的办法,看一下自己几个月前写的代码,如果觉得很烂,或者感觉有很多可以提升的地方,那么恭喜你,你进步了!

很多技术人在遇到烂代码时,常常会忽略掉它们,这些同学的想法可能是:
能用就行了,技术人就要懒。
算了,别折腾了,万一写个Bug就完蛋了。
先把迭代icon做完再说吧,开发时间在那里呢。
等开发新系统的时候好好设计下吧。

我们知道计算机是一门实践科学,只是研究理论,或者只有想法是很不够的,否则程序就不会经常出现问题了。要去俯下身来敲代码、去实践,然后再总结迭代,一步步的完善,形成一个看起来差不多的方案。

技术设计能力或者架构能力的迭代也是在实践中不断打磨的,而这种磨练的绝佳机会就是工作接触到的各种程序,它们是真实的业务系统,其中的问题也是实实在在的就在那里,这比各种架构课的模拟练习更加贴近实际,也更能给人带来深刻的认识。

再者会有那么多的新系统让你开发,让你去不断地挖坑吗?我们都知道技术债这个东西,如果欠的太多,就更难翻身了。趁着代码还不是那么烂,赶紧改起来吧。
展开
萤火架构于2022-07-26 10:29发布的图片
12
前几天有个API报错,原因是某个参数为空,后端也没有进行检验,然后某个场景下就产生了一个NPE错误。

经过调查,在前端的这个特定场景下确实取不到API所需要的参数,因此此时不应该调用API。不过有个后端同事提议可以改成API内部允许为空,这样就不报错了,前端获取不到数据也没有问题。这确实也能解决问题,不过被我立即制止了。

首先这改变了API的定义,API的规格被改变了,这是一件值得警惕并要慎重对待的事情,很多时候程序越来越乱就是随意改变方法或者类型的业务定义,看似改动很小,不过却埋下了很大的隐患,这样的改动越多,程序就会变为一堆乱麻,正所谓改动一时爽,维护火葬场。

API的定义应该严格匹配业务功能需求,不能一个API即能处理这个业务又能处理那个业务,API处理的业务要有明确的边界,不同方法或者API之间应该是正交分解的。这个原则也可以适配子系统、模块、类、方法的定义。

然而很多时候改程序是一件不可避免的事,这可能源于开发者的疏漏,也可能是产品需求的迭代,还可能是开发者对业务的认识调整,那么正确的做法是怎么样的呢?

如果不改变业务的定义,或者只是修改一个Bug,那么直接改就好了,这不会产生副作用。如果涉及到业务边界的改变,那么定义一个新的API更好,可以用新的更能代表业务的名字,或者用新的版本号来进行区分。再改再定义新的API,也就是说定义好的API始终应该是只读的,它们都有明确的业务范围,这样就不会乱,修改也更加安全。
展开
萤火架构于2022-07-25 13:02发布的图片
评论
技术这么多的东西怎么记得住?昨天review代码的时候,有个同事一时找不到修改的地方了,说了一句: 这么多东西怎么记得住?我很快意识到这是一个很有意思的话题。

一个业务系统随着不断地迭代推进,会有越来越多的功能加进来,细节也会很多,而且有的功能过了很久才又要修改,当初怎么做的脑子里也模糊了。说实话,虽然整体的架构是我设计的,但是具体到细节,也得翻文档看代码,我认为这是很正常的,毕竟大家都是普通人,脑容量有限。

但是这件事还是有聊聊的必要,因为出现了问题,有的人能够很快的解决,有的人却半天搞不清楚问题,更别说给出合适的解决方案了。这是为什么呢?接触的时间短?把时间拉长,这样的现象还是很常见。我认为一个很关键的问题是很多人只见树木不见森林,脑子里没有系统的整体结构,看到一个问题就是一个问题,就在这个出问题的地方打个补丁好了,没有想过数据为什么是这样的,在这里打个补丁是不是最好的选择。

我想起来一个很久远的事,上初中的时候,老师让学生自己出试卷,现在想想真是一个掌握知识的好方法,你如果认真去做,就要把主要的知识点捋一下,找出其中的重点和容易出错的地方,这样就能把整个知识体系建立起来。我感觉自己有时候能去把一个问题或东西分成几个要点去讲清楚,也许就是从这时候锻炼起来的。

再回到系统开发这块,原理都是相通的,你所负责的业务系统就那么几大块,他们都是干什么的,搞清楚,再往下有哪些模块,又是怎么分的。常见的业务需求都是用哪些技术方案实现的,数据是怎么流转的,搞清楚模式。出了问题或者要修改的时候,找对地方就不难了。

再延伸一点,对于整个计算机知识的掌握也是如此。有那么多的硬件,那么多的操作系统,那么多的语言和框架,说精通每一个,这样的人我还没见过,当然在一段时间内精通还是很常见的。计算机知识这么繁杂,怎么学怎么用?原理还是相通的,先掌握脉络,用到哪个再去深入哪个?比如先打好基础: 计算机组成原理、计算机网络、操作系统、数据结构与算法,原理性的东西先搞明白,然后学语言、学框架,里边处理的问题也就是各种数据结构和算法、IO、线程icon、持久化、分布式等等一些相通的东西。
展开
萤火架构于2022-07-23 23:05发布的图片
1
后端工程师的未来在哪里?前段时间听许世伟大佬提到一个观点,后端工程师这个角色会最终消亡,会回到最初软件开发的样子,不分前端和后端。

这个事怎么理解呢?全栈工程师?太简单了吧!
我这里尝试总结一下大佬的观点:
1.首先服务端的本质是什么?服务端是用来持久化业务状态的。用什么持久化呐?各种存储中间件。一开始业务状态保存在本地,随着网络应用的兴起,才有了服务端,并将业务状态保存在服务端。
2.随着服务端技术的发展,各种存储中间件的能力不断提升,随着云原生技术的进展,服务治理也越来越简单,智能化水平不断提高。也许有一天后端们都不用写代码了,只要写写SQL就行了,再搞搞界面,业务就完成了。

大概是这个意思,可能有错漏,不过想想真有可能,现在各种存储和数据处理中间件都去支持SQL,写什么后端代码,全写SQL就够了!再看看低代码的流行,还要什么自行车!?到时候可能只有两种工程师:业务开发工程师和基础软件工程师,业务开发就是界面+SQL。
展开
2
老话长谈,k8s为什么放弃docker?这个说法是有点问题的,k8s没有放弃docker,放弃的是对dockershim的官方支持,这个东西是为了兼容k8s自身的容器管理接口而做的一个docker兼容层,原来是k8s自己维护,现在它不想管了,交给别人去折腾吧。

这个事就像谈恋爱,一开始大家会相互将就,或者一方多忍受另一方一些,时间长了,形势发生了变化,双方或者有一方不想将就了,就分手了。一开始k8s很弱小,docker很火爆,k8s要想成长就要多借助docker的力量,但是慢慢地k8s也长成了参天大树,就有了很多自己的小目标,就可以要求docker来兼容自己,自己也专注做好自己就行了。
展开
萤火架构于2022-07-22 09:14发布的图片
评论
前段时间面试了几个后端工程师,很多有几年经验的人还搞不清楚进程和线程的区别。虽然现在都是使用成熟的框架,只要比着画就行,对写业务程序影响不大,但遇到一些棘手的问题,需要进一步提升性能的时候,这些人往往就不知道怎么办才好了,或者从哪方面入手才能达到效果。这可能也符合二八定律,百分之八十的工作只需要百分之二十的学习时间,其它百分之二十的工作确需要花费更多的学习时间。

如果你已经搞清楚了进程和线程的区别,那么CPU中的超线程技术和操作系统的线程有什么关系?
展开
萤火架构于2022-07-20 09:46发布的图片
评论
Bson和Jsonicon有什么区别?做过Web API开发的同学对Json应该很熟悉,基本上所有对外的API都采用这种数据交换格式。

那么Bson是什么东西呢?简单点说就是binary json,二进制json。如果你接触过mongodbicon,对它就很眼熟了。mongodb使用这种格式存储数据。

这个格式有个好处是查找数据比较方便,它在每个元素前边加了元素数据长度的前缀,这样查找数据时可以比较容易地跳到需要的位置。

它还支持一些json没有的数据格式,比如日期和byte数组,这都是为了方便存储数据。

对于数字类型,它至少使用4个字节,这样修改数字时很多时候无需扩展元素长度,不过对于小点的数字也会浪费空间。

大概率上,对于同样的数据,bson需要的空间可能会比json大一些。
展开
评论
下一页
个人成就
文章被点赞 1,036
文章被阅读 97,789
掘力值 4,400
收藏集
0
关注标签
9
加入于