V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  AlexEzio  ›  全部回复第 1 页 / 共 1 页
回复总数  7
2021-12-27 10:56:28 +08:00
回复了 jbue520 创建的主题 NGINX Ngnix 奇怪问题...不知道怎么解决
这个问题和 nginx 没有关系, 原因在于出口多线路时,网关路由策略的选择导致了不同路线出口。
内网客户端无法决定网关路由策略,因此最佳方案是通过网关层策略修改来达到预期的效果。

解决方法:
# 网关层
1. 固定外网 IP ,建议把所有 IP 加入微信白名单,因为多线路场景,对应的是多运营商与负载均衡,不同运营商的流量走不同的路线,以获取最佳速度
2. 如果 IP 过多,想指定某一条路线走特定流量,可以通过路由层,加上策略路由,通过七层策略,匹配所有*.weixin.com 的 http host 头流量走特定 IP 出口。
# 客户端层
3. 如果路由层不支持七层策略,可以咨询运维人员,获取具体的四层策略,比如联通 IP 走哪个,电信 IP 走哪个。 然后手动修改服务器 host ,将微信服务器指向特定的运营商 IP , 来保持请求总是走到对应的外网路线上
4. 如果外网是动态 IP ,客户端需要编写脚本,定期获取自己的外网地址,然后通过微信的 api,进行白名单刷新。 这也是常用手段之一
2021-06-04 14:12:53 +08:00
回复了 beryl 创建的主题 Kubernetes 是否有必要用 K8S
@sangs
不要跳脱上下文噻,讨论是基于题主那个情况, 如果真有 52 个 image, 那项有化项目整体规模都不一样了,对应技术方案肯定是变化的。
另外我强调的几点, 是就题主这个情况,docker,和 k8s 私有化部署
1. docker 部署效率 > k8s 部署效率
2. docker 可维护性 >> k8s 可维护性
3. docker 私有化也是容器部署,不存在你说的生产研发不一致的情况,docker 和 k8s 对研发来讲都是一样的,最终部署都是一个 image,无非是 k8s 有更完善的扩容,抽象资源,调度机制。
2021-06-03 11:57:02 +08:00
回复了 beryl 创建的主题 Kubernetes 是否有必要用 K8S
@beryl k8s 学习成本大,维护成本也高。如果有专人做 k8s,搭建,维护啥的,那肯定会方便一些,helm chat 加上写好的 yaml 梭就行了。 但是这个专人成本也会高,风险也很大,如果这个人走了,后续集群更新,漏洞修复,证书更新啥的,都是麻烦事。
docker 编排,和 k8s 编排,迁移成本就是在各类资源 yaml 或 helm chat 编写上, 对开发来讲是无感的。

说下我目前交付的场景:
1. POC 部署, 直接 docker-compose 一把梭,一台机器搞定,就是演示核心功能
2. 测试,UAT,生产部署: 用 ansible + 源码编译的形式, 中间件能复用客户的,就复用客户的,这样只需要专注于自己的业务这块。这种适用于有自己技术团队的客户,ansible 多机部署非常方便,设计好 playbook, 设计好 role 的复用就可以了。我目前都是这种方式为主,规模从几台,到几十台不等都 okay.
3. k8s 部署, 这种都是客户自己有上云需求,会要求你去对接他们 cicd, k8s, 成本就是前期的上云适配, 后续维护除了版本更新,其他都是客户自己负责。 这种方式比较小,客户很少有完善和成熟的云原生维护体系。
4. 小众的 paas 平台适配, 这种就更少了。基本前两种为主。

私有化这块,没有什么一成不变的交付方式,尤其是大客户这一块,会经常有定制,对接需要。
还是根据你们自己的情况,去制定一个效率和维护都兼顾的一种交付方式,先小步跑起来。
2021-06-03 10:50:44 +08:00
回复了 beryl 创建的主题 Kubernetes 是否有必要用 K8S
@beryl 私有化场景,k8s 和 docker 一把梭这种比起来,标准化一致(k8s 同样也是利用容器技术来实现运行时的标准化),效率天差地别。 部署一套 k8s,和部署 docker daemon,那就是一天和几分钟的区别。
2021-06-03 10:47:49 +08:00
回复了 beryl 创建的主题 Kubernetes 是否有必要用 K8S
@beryl 恩,我这里表述有点问题。实际我说的就是私有化中,用 k8s 交付服务这种场景。
据我个人经验,私有化如果有服务需要依托于 k8s 交付,客户最起码项目预算应该是百万以上,而且基本都是金融,银行,互联网公司这种不差钱的居多,有自已运维团队。
不过话说回来,如果是这种客户,那落地用什么架构,用什么技术,就不是你们说了算,而是客户说了算。
小项目,用 docker+ansible 轻装上阵, 快速部署加回款验收才是王道,整那些花里胡哨的没用, 对老板来说,项目成不成功,只看回款和金额, 不是看你用了多牛 b 的技术。
当然,想借项目来锻炼自己技术也是可以的, 我也试过 k8s 交付服务, 但是相信我,人总是趋利避害的,事少一点不好嘛~
2021-06-03 10:32:37 +08:00
回复了 beryl 创建的主题 Kubernetes 是否有必要用 K8S
ToB 交付老油条(4 年经验)来回答:
就你目前所说的信息,完全没有必要上 k8s.
k8s 的优势在私有化部署中并不明显,因为运维成本高,而且不可控,不是所有客户都玩得转 k8s, 而且你评估下一个客户一个 k8s 的维护量?
私有化部署最重要的两点:
1. 部署效率与标准化(决定了交付速度,现金流的稳定)
2. 可维护性(决定了后续的维护成本)
在这两点上,k8s 私有化都只有缺点。
k8s 的优势在于应用的 zero downtime,扩容,发布,cicd, 这些私有化都不需要,私有化更新的频率,可能是一个月,基于半年,一年一次。


你这种场景,我之前也设计过部署方案,就是一套 docker-compose 搞定(我司当时是 12 个左右的 image)。定义好 docker entrypoint, 配置变量放在 env 文件里,初始化时脚本替换一下,加下 docker 自带的容器发现,很容易几分钟之内就部署好一套标准的环境出来。

配合上 ansible, 自己二开的 compose 配置平台, 能轻松实现部署,监控,预警,自动发布的效果。

另外,k8s 私有化是什么场景? 都是针对金融,银行机构,做容器平台私有化,像 daocloud, 青云这种,都有相关的业务,一个项目就是上亿,这种都需要客户自己有专业的运维,开发团队的。
2021-04-21 20:26:24 +08:00
回复了 balabalaguguji 创建的主题 编程 我来说说异步框架的最大缺点
异步编程本身就和多线程编程,多进程编程属于并发编程领域的不同范式。编程时需要注意代码是否是阻塞,就像多线程需要注意各类资源安全问题, 多进程需要考虑资源共享问题。 不同范式,在编程时考虑的关注点是不一样的,这并不是异步的缺点,恰好是其特性;只是异步编程本身调试起来就比较麻烦,很多人没有深入了解过,肯定是会经常阻塞程序的。

python 你应该了解的并不多。
cpython 由于 GIL 的存在,多线程模型下,往往只能使用单核的计算资源,因此通过多线程来解决 c10k 问题并不现实,所以在早期才有 twist, gevent 这种第三方的异步库.
python3.5 原生实现了异步,加入了 async/await 关键字。3.7 使用 c 实现了异步库,社区对各种基本中间件的异步支持也非常好,并不存在你说的支持少的情况。
go 的优势不需要过多学习,掌握了基础库使用后,就可以写出性能很好的程序. 而不需要关心过多关心底层的调度,并发之类的,这些基础库都帮你做好了。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2814 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 07:34 · PVG 15:34 · LAX 23:34 · JFK 02:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.