Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feedercoolshell.cn
酷 壳 – CoolShell
Get the latest updates from 酷 壳 – CoolShell directly as they happen.
Follow now 1370 followers
Latest posts
Last updated over 1 year ago
是微服务架构不香还是云不香？
over 1 year ago
这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH???刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。 今天上午有好几个朋友在微信里转了三篇文章给我，如下所示： 《微服务是不是个蠢主意？》 《单体回归？亚马逊放弃用于视频监控的微服务 》 《从微服务转为单体架构、成本降低...
我看ChatGPT: 为啥谷歌掉了千亿美金
almost 2 years ago
两个月前，我试着想用 ChatGPT 帮我写篇文章《eBPF 介绍》，结果错误百处，导致我又要从头改一遍，从那天我觉得 ChatGPT 生成的内容完全不靠谱，所以，从那天开始我说我不会再用 ChatGPT 来写文章（这篇文章不是由 ChatGPT 生成），因为，在试过一段时间后，我对 ChatGTP 有基于如下的认识：...
聊聊 nostr 和 审查
almost 2 years ago
这两天在网络上又有一个东西火了，Twitter 的创始人 @jack 新的社交 iOS App Damus 上苹果商店（第二天就因为违反中国法律在中国区下架了），这个软件是一个去中心化的 Twitter，使用到的是 nostr – Notes...
感染新冠的经历
almost 2 years ago
写一篇与技术无关的文章，供大家参考。我住北京朝阳，从上周三开始我家一家三口陆续发烧生病，自测抗原后，都是阳性。好消息是，这个奥密克戎跟一般的病毒性感冒差不多，没什么可怕的，不过，整个过程除了发病之外还有一些别的因为感染带出来的事，大家也需要知晓，以准备好，以免造成生活的不便，更好的照顾好自己和家人。 整个过程 我先说一下整个过程（我会不断更新这个过程，直到转阴） 先是我家孩子（12 岁）。上周三（12 月 7 日），孩子早上起来就说头疼，一测体温，38 度 5，就停止上网课，老实休息了，我们并没给孩子吃什么药，到了晚上，孩子的体温到了 39.4，嗓子疼，我老婆用酒精给孩子物理降温，成功降到了 38.2...
eBPF 介绍
almost 2 years ago
很早前就想写一篇关于eBPF的文章，但是迟迟没有动手，这两天有点时间，所以就来写一篇，这文章主要还是简单的介绍eBPF 是用来干什么的，并通过几个示例来介绍是怎么玩的，这个技术非常非常之强，Linux 操作系统的观测性实在是太强大了，并在 BCC 加持下变得一览无余。这个技术不是一般的运维人员或是系统管理员可以驾驭的，这个还是要有底层系统知识并有一定开发能力的技术人员才能驾驭的了的。我在这篇文章的最后给了个彩蛋。 介绍 eBPF（extened Berkeley Packet Filter）是一种内核技术，它允许开发人员在不修改内核代码的情况下运行特定的功能。eBPF 的概念源自于 Berkeley...
聊聊团队协同和协同工具
about 2 years ago
这两天跟 Cali 和 Rather 做了一个线上的 Podcast – Ep.5 一起聊聊团队协同。主要是从 IM 工具扩展开来聊了一下团队的协同和相应的工具，但是聊天不是深度思考，有一些东西我没有讲透讲好，所以，我需要把我更多更完整更结构化的想法形成文字。（注：聊天聊地比较详细，本文只是想表达我的主要想法） 国内外的企业...
从一次经历谈 TIME_WAIT 的那些事
over 2 years ago
今天来讲一讲TCP 的 TIME_WAIT 的问题。这个问题尽人皆知，不过，这次遇到的是不太一样的场景，前两天也解决了，正好写篇文章，顺便把 TIME_WAIT 的那些事都说一说。对了，这个场景，跟我开源的探活小工具 EaseProbe 有关，我先说说这个场景里的问题，然后，顺着这个场景跟大家好好说一下这个事。 问题背景 先说一下背景，EaseProbe 是一个轻量独立的用来探活服务健康状况的小工具，支持http/tcp/shell/ssh/tls/host以及各种中间件的探活，然后，直接发送通知到主流的IM上，如：Slack/Telegram/Discrod/Email/Team，包括国内的企业微信/钉钉/飞书， 非常好用，用过的人都说好...
ETCD的内存问题
over 2 years ago
今天跟大家分享一个etcd的内存大量占用的问题，这是一个前段时间在我们开源软件Easegress中遇到的问题，问题是比较简单的，但是我还想把前因后果说一下，包括，为什么要用etcd，使用etcd的用户场景，包括etcd的一些导致内存占用比较大的设计，以及最后一些建议。希望这篇文章不仅仅只是让你看到了一个简单的内存问题，而是让你有更多的收获。当然，如果觉得我们的开源软件做得不错，也欢迎关注我们的开源软件。 为什么要用ETCD 先说一下为什么要用etcd。用一个我们自己的实践说明一下吧，也说是我们自己做的一个API网关 – Easegress（源码） Easegress 是我们开发并开源的一个API应用网关产品，这个API应用网关不仅仅只是像nginx那样用来做一个反向代理，这个网关可以做的事很多，比如：API编排、服务发现、弹力设计（熔断、限流、重试等）、认证鉴权（JWT，OAuth2，HMAC等）、同样支持各种Cloud Native的架构如：微服务架构，Service Mesh，Serverless/FaaS的集成，并可以用于扛高并发、灰度发布、全链路压力测试……等更为高级的企业级的解决方案。所以，为了达到这些目标，在2017年的时候，我们觉得在现有的网关如Nginx上是无法演进出来这样的软件的，必需重新写一个（后来 Hashicrop也应该跟我们的想法一样，所以，也写了一个envoy，只不过，Envoy是用C++写的，而我用了技术门槛更低的Go语言） 另外，Easegress最核心的设计主要有三个： 一个是无第三方依赖的自己选主组集群的能力...
“一把梭：REST API 全用 POST ”
almost 3 years ago
写这篇文章的原因主要还是因为V2EX上的这个贴子，这个贴子中说—— “对接同事的接口，他定义的所有接口都是 post 请求，理由是 https 用 post 更安全，之前习惯使用 restful api ，如果说 https...
谈谈公司对员工的监控
almost 3 years ago
今天看到微博上有一个热点事件， 是一个关于某公司做的一个监控员工离职倾向的软件，从截图中可以看到员工访问招聘网站的次数，还有投递的简历以及搜索的关建词等等信息，通过这些信息分析员工的离职倾向。然后我发一个微博，说了一下，我以前工作过的公司无论外国公司还是中国公司都有这样的情况，收到一些人来问我相关的情况，所以，我想还是写篇文章详细地说一下，我对这种事情的看法。 本文分成下面个部分： 公司是监控员工的技术手段有哪些？ 为什么要监控员工？ 外企和国企有什么不一样？ 我对此事的看法 技术手段 下面是我经历过的几个手段： 1）通过网络嗅探的方式。也就是说，你只要上了公司的网络，你个人设备上的通讯信息就可以被人以网格抓包+分析的方式进行分析。当然，这样的手段忆经不怎么好用了，因为现在的网络基本上都是HTTPS加密的，网络嗅探的???式只能知道你访问了什么IP，对于其中的数据是没有办法知道的。 2）通过使用公司的提供软硬件工具。你使用公司的电子邮箱，浏览器（或是公司的代理服务器），通讯工具（包括语音电话），手机办公应用……等来处理你的个人事宜的时候，必然会被监控。这样，你只需要不要使用公司的软件来处理自己的私事就好了。 3）通过安装一个监控程序。这个是最可怕的了，因为无论你加不加密都没用了。一般来说，你不安装这个程序，你就没有办法连上网络，包括公司内网和外网。这个监控程序，会收集你电脑或手机上能够收集的到的所有的信息，比如，你的网络信息，按键操作，录屏，软件数据……等等。...
网络数字身份认证术
almost 3 years ago
这篇文章是《HTTP API 认证授权术》的姊妹篇，在那篇文章中，主要介绍了 HTTP API 认证和授权技术中用到的 HTTP Basic, Digest Access, HMAC, OAuth...
我做系统架构的原则
almost 3 years ago
过去几年里看到了很多公司的一些问题很多的系统架构，让我感觉现在很多人做架构基本不讲章法了，随心所欲，张冠李戴。所以，想写下这篇文章，总结一些我个人的经验和想法希望能够让更多的人更好的学会做做架构。注意，这篇文章所说的这些架构上的原则，一般适用于相对比较复杂的业务，如果只是一些简单和访问量不大的应用，那么你可能体会的并不是这么深。 原则一：关注于真正的收益而不是技术本身 对于软件架构来说，我觉得第一重要的是架构的收益，如果不说收?益，只是为了技术而技术，而没有任何意义。对于技术收益来说，我觉得下面这几个收益是非常重要的： 是否可以降低技术门槛加快整个团队的开发流程。能够加快整个团队的工程流程，快速发布，是软件工程一直在解决的问题，所以，系统架构需要能够进行并行开发，并行上线和并行运维，而不会让某个团队成为瓶颈点。（注：就算拖累团队的原因是组织构架，也不妨碍我们的系统架构设计） 是否可以让整个系统可以运行的更稳定。要让整个系统可以运行的更为的稳定，提升整个系统的 SLA，就需要对有计划和无计划的停机做相应的解决方案（参看《关于高可用的架构》） 是否可以通过简化和自动化降低成本。最高优化的成本是人力成本，人的成本除了慢，还有经常不断的 human error。如果不能降低人力成本，反而需要更多的人，那么这个架构设计一定是失败的。除此之外，是时间成本，资金成本。 如果一个系统架构不能在上面三个事上起到作用，那就没有意义了。 原则二：以应用服务和 API...