Mind of Bigyellow

Update pyenv version cd ~/.pyenv git pull Use new version pyenv install 3.9.0 pyenv global 3.9.0 pyenv local 3.9.0 eval "$(pyenv init -)" pyenv shell 3.9.0 poetry init poetry install  poetry env use 3.9.0 poetry shell poetry add <dependencies>  <dependencies> poetry add -D <dependencies>  <dependencies> // existing project :   $ for item in $(cat requirements.txt); do poetry add "${item}"; done poetry shell code . https://www.pythoncheatsheet.org/blog/python-projects-with-poetry-and-vscode-part-2/ https://www.pythoncheatsheet.org/blog/python-projects-with-poetry-and-vscode-part-3/ https://aber.sh/articles/python-poetry/ install poetry install python from official site,  DO NOT add python to PATH, user have to be in venv to use python. poetry  init -   Create pyproject.toml poetry env use PYTHONPATH - Create virtual env,  PYTHONPATH is where python.exe poetry install & update,  install and update poetr...

复杂性是不可避免的，这就是进化的原理。 考虑系统复杂性对开发速度的影响因素 红色区块： 不利于开发速度 绿色区块： 有利提升开发效能 黄色区块： 需适度选择 红线： 造成下降 绿线： 造成增加 星号： 改善重点 倒三角： 危害重点 这里的解决复杂性，所指的是软件开发单位如何提升开发速度，想方设法加快开发效能；这可能是所有的CEO们都梦寐以求的，因为有太多的需求在排队等着要做了，但却偏偏卡在这里，一定要设法来加快开发单位的效能才是。 身为顾问，我经常受邀去诊断研发单位为何效能不彰的问题，习惯上我都会私下先跟负责人强调："一个够好的需求，胜过作好无数个实用的功能。"在开发之前；多花一点时间排好需求开发的优先序才是上策。 但怎么说了却无法激发当事人的反思（基本上从来没有生效过）而有所改变。很快的他们就会要求各个部门配合我进行诊断作业，然后催促着要我交报告，急著做决策，那种急切心情很教人激赏，我又怎能辜负它呢。 上图是参考 Targetprocess 公司 Michael Dubakov 先生在 Blog 上所发表的著作(注2. 原文)，它是拿来分析软体开发速度相关元素的极好的参考资料，这里我仅仅撷取与系统复杂性有关的区块翻译成中文。加了一点实作上的考量(原文抽象度太高)，但在右上角我加进了「架构设计」的影响，并给予它和程序技巧区块一个 AND 的属性。意思是好的架构与好的程序技巧都能消减系统的复杂性。而程序设计巧甚至会受到架构设计的制约(限制)，所以我擅自加了一个绿色的区块跟一个椭圆的符号。因为这也是我最常建议开发单位进行改善时的起始点(所以用三颗星来显示)。 快速直觉的抉择方式，往往缺少了深思熟虑。 针对解决复杂统架构实作的通则 技术债 Technical debt 这个观念是由 Wiki 之父 Ward Cunningham 先生提出来的，也是开发单位效率不彰最常见的元凶，就是只知道要求开发速度(注1. 技术债的真正定义，指工程师挑选了实践非最佳解决方案或编写非最佳程式码的刻意决定，以便能够更快地发布软体功能。)，而忽略了自己正在提油救火，让约束(限制你开发速度的瓶颈)变得更大了。给它二颗星是因为我们应该正视并支持工程师适时作正确抉择的心态，勇于去挑战技术债才是对提升效能作出最好的贡献。 开发单位其实在邀请外部顾问作诊断之前，都已经作了自我改善的努...

https://tinyurl.com/y4kwd4c3    面对超高的并发，首先硬件层面机器要能扛得住，其次架构设计做好微服务的拆分，代码层面各种缓存、削峰、解耦等等问题要处理好，数据库层面做好读写分离、分库分表，稳定性方面要保证有监控，熔断限流降级该有的必须要有，发生问题能及时发现处理。这样从整个系统设计方面就会有一个初步的概念。 微服务架构演化 在互联网早期的时候，单体架构就足以支撑起日常的业务需求，大家的所有业务服务都在一个项目里，部署在一台物理机器上。所有的业务包括你的交易系统、会员信息、库存、商品等等都夹杂在一起，当流量一旦起来之后，单体架构的问题就暴露出来了，机器挂了所有的业务全部无法使用了。 于是，集群架构的架构开始出现，单机无法抗住的压力，最简单的办法就是水平拓展横向扩容了，这样，通过负载均衡把压力流量分摊到不同的机器上，暂时是解决了单点导致服务不可用的问题。 但是随着业务的发展，在一个项目里维护所有的业务场景使开发和代码维护变得越来越困难，一个简单的需求改动都需要发布整个服务，代码的合并冲突也会变得越来越频繁，同时线上故障出现的可能性越大。微服务的架构模式就诞生了。 把每个独立的业务拆分开独立部署，开发和维护的成本降低，集群能承受的压力也提高了，再也不会出现一个小小的改动点需要牵一发而动全身了。 以上的点从高并发的角度而言，似乎都可以归类为通过服务拆分和集群物理机器的扩展提高了整体的系统抗压能力，那么，随之拆分而带来的问题也就是高并发系统需要解决的问题。 RPC 微服务化的拆分带来的好处和便利性是显而易见的，但是与此同时各个微服务之间的通信就需要考虑了。传统HTTP的通信方式对性能是极大的浪费，这时候就需要引入诸如Dubbo类的RPC框架，基于TCP长连接的方式提高整个集群通信的效率。 我们假设原来来自客户端的QPS是9000的话，那么通过负载均衡策略分散到每台机器就是3000，而HTTP改为RPC之后接口的耗时缩短了，单机和整体的QPS就提升了。而RPC框架本身一般都自带负载均衡、熔断降级的机制，可以更好的维护整个系统的高可用性。 那么说完RPC，作为基本上国内普遍的选择Dubbo的一些基本原理就是接下来的问题。 Dubbo工作原理 服务启动的时候，provider和consumer根据配置信息，连接到注册中心register，分别向注册中心...

准备用家里的就设备搭建一个k8s 的 cluster 。  准备用ovirt虚拟化，这样就可以把新的旧设备随时加入cluster。   碰到几个坑 1.  一台笔记本装ubuntu 20.10，一从usb启动就是  "symbol 'grub_calloc' not found，试了几个办法也不行，不过改装20.04LTS就没事。  装oVirt，只能装在RH系列下面 1.  CentOS8，如果安装的时候就用LAN接网络，启动以后找不到LAN，  2.  oVirt Host有最低CPU要求，家里有台Core microarchitect的笔记本就没法接入cluster了 3.  如果在local设置data storage domain，一定要注意把local path放在那个目录下面                                              df -h  看一下partition的大小，在我的320G硬盘下面， CentOS默认root分区50G，home会比较大， 250G，如果把storage domain放在root下面的文件夹，那么storage domain最大只有50G，所以要放在大的分区下面，而且需要把owner改成， vsdm：kmv                                      chown -R 36:36   4.  Kubectl要求最少2个CPU。   5. Install kubernets following  https://phoenixnap.com/kb/install-kubernete...