点点和滴滴 — Yu Peng

yu3peng commented 4 years ago

https://www.y2p.cc/notes/note/

yu3peng commented 4 years ago

Gartner 曲线原理

第一条是舆论变化曲线，指一款新产品或者技术刚刚诞生时，新闻媒体为了获取流量喜欢夸大宣传、故意拉高期望值。一旦产品落地遇到困难或是市场不够成熟，媒体又会迅速产出负面新闻、进行打压。

第二条则是工程 & 商业成熟度曲线，基本不受外界舆论影响，所以期望值呈相对稳定的节奏逐渐爬升。

yu3peng commented 4 years ago

IBN: Intent-Based Network

yu3peng commented 4 years ago

诺基亚如何看待Open RAN？: 诺基亚对于Open RAN的理念是：既要开放，也要集成。Weldon表示，他不相信“白盒化”RAN会节省成本。换句话说，Open RAN的作用不在于降成本，而在于解耦运营商对设备商的锁定。

5G时代，OpenRAN会威胁华为和爱立信的地位吗？

yu3peng commented 4 years ago

根据加拿大多伦多大学的研究成果表明：同等算力情况下，FPGA能耗是ASIC的12倍。据此推测，白盒设备采用通用CPU+FPGA的架构，相比于专有硬件采用一体化高集成的ASIC芯片，运行LTE业务能耗要高10倍以上。

基于5G大带宽、多天线、低时延等特点，这一能耗差距甚至可能达到20倍以上。

前面我们说华为没有加入O-RAN，其中主要的原因之一，就是华为经过测试验证，发现4G基站使用搭载英特尔CPU的白盒硬件的表现，功耗要高出10倍。

yu3peng commented 4 years ago

O-RAN，真的会成功吗？

而问题的关键在于：

基站接入网这块市场，是否仍然存在暴利？值不值得运营商一怼再怼？

是不是吸引更多小公司入场，就一定是好事？成本一定能降低？还是说只是又多了一堆炮灰？

白菜价的白盒基站，是不是真的能省钱？是不是能够提供既安全又稳定的服务？

O-RAN联盟看似门庭若市，但里面的每个人都有自己的小算盘。

运营商推O-RAN，主要是拿它作为向设备商压价的砝码，同时也是对设备商长期不满情绪的一种宣泄。

天线厂商做O-RAN，主要是扩大自己的产品线，避免被边缘化，也是为了和大型设备商竞争。现在大型设备商几乎是什么都做，触角越伸越远，而细分产品设备商的日子越来越难过，急需一些反制的能力。

IT厂商做O-RAN，更多是为了挤进通信这个庞大的市场。同时，如果能切入接入网，将非常有利于自家边缘计算产品的发展。

中小型初创企业做O-RAN，更多是为了服务中小运营商，还有对成本敏感，对稳定性和性能不敏感的偏远地区，以及经济欠发达地区。他们可以通过O-RAN，在大型设备商不care的地方，抢一点市场份额。此外，搞白盒基站，可以迎合资本市场追捧5G的需要，提升估值，上市变现。

至于传统设备商的“加入”，其实更多是在态度上的支持，对甲方表示尊重，再则也是密切关注这个潜在竞争对手的动态，至于具体有没有出力，大家是心知肚明的。

在O-RAN的具体落地方面，虽然已有厂商做出了产品，但迄今为止，除了日本乐天这个新进入通信领域的小运营商之外，没有其它任何一家大型运营商批量使用白盒基站。国内5G建网在即，我相信三大运营商也不会此时对白盒基站进行大规模集采，更不可能贸然中止和传统设备商之间的合作。

总而言之，O-RAN所倡导的开放生态，肯定是未来通信网络发展的趋势。但想要短期内获得成功，是绝对不可能的。不管是从技术的角度来看，还是从生态的角度来看，O-RAN都还有很长的路要走。

yu3peng commented 4 years ago

Ironic 裸金属管理服务

yu3peng commented 4 years ago

Harbor负责镜像管理，Dragonfly侧重镜像分发，具体就是在 Harbor 中可制定预热 (preheat) 策略，把镜像预先发送到 Dragonfly 超级节点的缓存中，后续集群中镜像的 P2P分发可以由 Dragonfly 完成。 Harbor定义了 P2P provider的规范，可以和 Dragonfly 等 P2P 引擎对接。当镜像推送到 Harbor 后，根据用户定制的策略，可通知 P2P 分发软件进行镜像的预热，提前分发应用的镜像。

yu3peng commented 4 years ago

Gartner：云原生基础设施未来的八大趋势

趋势2：边缘计算（Edge Computing）原因：

（1）轻量级容器比虚拟主机更适应边缘环境；

（2）微服务带来的模块化。

市场状态：

容器化很可能成为边缘计算应用的主流分发方式，物联网平台商开始采用容器作为边缘计算基础设施。Microsoft Azure物联网边缘计算平台允许供应商添加Docker容器作为边缘模块、AWS IOT Greengrass支持部署Docker容器或快照、Balena.io项目支持跨设备部署和管理容器。Kubernet虽为数据中心而生，但在边缘环境中也有应用，Chick-fil-A在其2000多家门店中构建三节点kubernetes集群，像Rancher这样软件供应商也在开发可用于边缘计算的轻量级kubernetes。

推动厂商及其产品：

AWS IoT Greengrass (IoT edge software)
Microsoft Azure IoT Edge (IoT platform service)
Rancher k3s (Lightweight Kubernetes distribution)

建议：

选择支持容器的物联网平台，在边缘尝试部署容器。
轻量级Kubernetes可能有效，要确保与边缘设备及运行的应用兼容。

yu3peng commented 4 years ago

腾讯 gpu-manager 启动流程分析

yu3peng commented 4 years ago

Nvidia收购Mellanox背后的野心和启示

yu3peng commented 4 years ago

https://blog.csdn.net/Yixin_Hu/article/details/90272302

yu3peng commented 4 years ago

https://youtube-dl.org/

https://github.com/soimort/you-get

yu3peng commented 3 years ago

https://katacoda.com/courses/ubuntu/playground

docker run -it ubuntu:16.04 /bin/bash

apt update

apt install sudo

apt install software-properties-common

sudo add-apt-repository ppa:deadsnakes/ppa

sudo apt update

sudo apt install python3.6

sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.5 1

sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.6 2

sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 100

sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 150

curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py

python get-pip.py --force-reinstall

pip install jieba django==2.1.3 numpy gensim tushare pandas Scikit-learn==0.20.4 pyecharts==0.1.9.4

git clone https://github.com/LinLidi/StockSensation.git

export PYTHONIOENCODING=utf-8

cd StockSensation

python manage.py runserver 0.0.0.0:8000 &

wget 127.0.0.1:8000

yu3peng commented 3 years ago

mkdir -p /data/mariadb/data

docker run --name mariadb -v /data/mariadb/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=mariadb -p 3306:3306 -d mariadb:latest

docker run -itd --link=mariadb --name stock -v /data/notebooks:/data/notebooks -p 8888:8888 -p 9001:9001 -p 9999:9999 pythonstock/pythonstock:latest

docker run --name myadmin -d --link mariadb:db  -p 8080:80 phpmyadmin

说明，启动容器后，会调用。run_init.sh 进行数据初始化，同时第一次执行后台执行当日数据。以后每日18点（只有18点左右才有今日的数据）进行股票数据抓取并计算。

# 进入容器
docker exec -it stock bash 
sh /data/stock/jobs/cron.daily/run_daily

本地访问端口 http://localhost:9999 股票系统

http://localhost:8888 jupyter 查看jupyter的密码： docker exec -it stock bash 查看登录 token： jupyter notebook list 就可以看到 token 了，然后可以登录了。

http://localhost:9001 supervisor

http://localhost:8080 phpmyadmin u/p: root/mariadb

yu3peng commented 3 years ago

量化分析师的Python日记

yu3peng commented 3 years ago

from sqlalchemy import create_engine,Table,Column,Integer,String,MetaData,ForeignKey
engine=create_engine("mysql+mysqldb://root:mariadb@mariadb:3306/test?charset=utf8",  encoding='utf8', convert_unicode=True)
metadata=MetaData(engine)

user=Table('user',metadata,
            Column('id',Integer,primary_key=True),
            Column('name',String(20)),
            Column('fullname',String(40)),
            )
address_table = Table('address', metadata,
            Column('id', Integer, primary_key=True),
            Column('user_id', None, ForeignKey('user.id')),
            Column('email', String(128), nullable=False)
            )

metadata.create_all()

yu3peng commented 3 years ago

docker 部署 mysql + phpmyadmin 3种方法

yu3peng commented 3 years ago

浅谈 Kubernetes Scheduling-Framework 插件的实现

Yoda是一个基于GPU参数指标的 Kubernetes 调度器

yu3peng commented 3 years ago

GPU集群管理系统

OSDI'20 论文赏：AntMan: Dynamic Scaling on GPU Clusters for Deep Learning

阿里巴巴如何扩展Kubernetes 调度器支持AI 和大数据作业

代码实现：GPU-scheduler-for-deep-learning

进击的 Kubernetes 调度系统（二）：支持批任务的 Coscheduling/Gang scheduling

yu3peng commented 3 years ago

NVIDIA GPU Operator分析一：NVIDIA驱动安装

NVIDIA GPU Operator分析二：NVIDIA Container Toolkit安装

NVIDIA GPU Operator分析三：NVIDIA Device Plugin安装

NVIDIA GPU Operator分析四：DCGM Exporter安

NVIDIA GPU Operator分析五：GPU Feature Discovery安装

NVIDIA GPU Operator分析六：NVIDIA GPU Operator原理分析

yu3peng commented 3 years ago

什么是 Service Mesh

Service Mesh 作为下一代微服务技术的代名词，初出茅庐却深得人心一鸣惊人，大有一统微服务时代的趋势。

那么到底什么是 Service Mesh？

一言以蔽之：Service Mesh 是微服务时代的 TCP/IP 协议。

有了这样一个感性的初步认知，我们再来看到底什么是Service Mesh。

提到Service Mesh，就不得不提微服务。根据维基百科的定义：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。目前业界跟微服务相关的开发平台和框架更是不胜枚举：Spring Cloud， Service Fabric，Linkerd，Envoy，Istio ...

这些纷繁的产品和Sevice Mesh有什么样的关联？哪些属于Service Mesh的范畴？

为了理清这些繁复的产品和概念，我们先来了解下微服务和Service Mesh技术的历史发展脉络。

了解清楚了技术的主要脉络，就能清晰的知道上述的各个平台、框架属于技术脉络中的哪个结点，其间的关系也就一目了然。

Phil Calçado的文章《Pattern: Service Mesh》，详细的介绍了从开发者视角来看，服务开发模式和Service Mesh技术的演化过程，个人认为是非常经典的学习Service Mesh的资料。这里借用文章的脉络，结合自己的理解并予以简化，试图说清楚ServiceMesh的概念和这项技术诞生的历史必然性。你可以把本文当做原文的一个中译版本来阅读。

时代0：开发人员想象中，不同服务间通信的方式，抽象表示如下：

时代1：原始通信时代

然而现实远比想象的复杂，在实际情况中，通信需要底层能够传输字节码和电子信号的物理层来完成，在TCP协议出现之前，服务需要自己处理网络通信所面临的丢包、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还夹杂着对网络传输问题的处理逻辑。

时代2：TCP时代

为了避免每个服务都需要自己实现一套相似的网络传输处理逻辑，TCP协议出现了，它解决了网络传输中通用的流量控制问题，将技术栈下移，从服务的实现中抽离出来，成为操作系统网络层的一部分。

时代3：第一代微服务

在TCP出现之后，机器之间的网络通信不再是一个难题，以GFS/BigTable/MapReduce为代表的分布式系统得以蓬勃发展。这时，分布式系统特有的通信语义又出现了，如熔断策略、负载均衡、服务发现、认证和授权、quota限制、trace和监控等等，于是服务根据业务需求来实现一部分所需的通信语义。

时代4：第二代微服务

为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的开发框架出现了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。

时代5：第一代Service Mesh

第二代微服务模式看似完美，但开发人员很快又发现，它也存在一些本质问题：

其一，虽然框架本身屏蔽了分布式系统通信的一些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事；其二，开发框架通常只支持一种或几种特定的语言，回过头来看文章最开始对微服务的定义，一个重要的特性就是语言无关，但那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到；其三，框架以lib库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的lib库升级而被迫升级；因此以Linkerd，Envoy，NginxMesh为代表的代理模式（边车模式）应运而生，这就是第一代Service Mesh，它将分布式服务的通信抽象为单独一层，在这一层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能，作为一个和服务对等的代理服务，和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求，这样上边所说的三个问题也迎刃而解。

如果我们从一个全局视角来看，就会得到如下部署图：

如果我们暂时略去服务，只看Service Mesh的单机组件组成的网络：

相信现在，大家已经理解何所谓Service Mesh，也就是服务网格了。它看起来确实就像是一个由若干服务代理所组成的错综复杂的网格。

时代6：第二代Service Mesh

第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，所有的单机代理组件通过和控制面板交互进行网络拓扑策略的更新和单机数据的汇报。这就是以Istio为代表的第二代Service Mesh。

只看单机代理组件(数据面板)和控制面板的Service Mesh全局部署视图如下：

至此，见证了6个时代的变迁，大家一定清楚了Service Mesh技术到底是什么，以及是如何一步步演化到今天这样一个形态。

现在，我们再回过头来看Buoyant的CEO William Morgan，也就是Service Mesh这个词的发明人，对Service Mesh的定义：

服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。这个定义中，有四个关键词：

基础设施层+请求在这些拓扑中可靠穿梭：这两个词加起来描述了Service Mesh的定位和功能，是不是似曾相识？没错，你一定想到了TCP；

网络代理：这描述了Service Mesh的实现形态；

对应用透明：这描述了Service Mesh的关键特点，正是由于这个特点，Service Mesh能够解决以Spring Cloud为代表的第二代微服务框架所面临的三个本质问题；

总结一下，Service Mesh具有如下优点：

屏蔽分布式系统通信的复杂性(负载均衡、服务发现、认证授权、监控追踪、流量控制等等)，服务只用关注业务逻辑；真正的语言无关，服务可以用任何语言编写，只需和Service Mesh通信即可；对应用透明，Service Mesh组件可以单独升级；

当然，Service Mesh目前也面临一些挑战：

Service Mesh组件以代理模式计算并转发请求，一定程度上会降低通信系统性能，并增加系统资源开销； Service Mesh组件接管了网络流量，因此服务的整体稳定性依赖于Service Mesh，同时额外引入的大量Service Mesh服务实例的运维和管理也是一个挑战；

历史总是惊人的相似。为了解决端到端的字节码通信问题，TCP协议诞生，让多机通信变得简单可靠；微服务时代，Service Mesh应运而生，屏蔽了分布式系统的诸多复杂性，让开发者可以回归业务，聚焦真正的价值。

yu3peng / blog-comments

点点和滴滴 — Yu Peng #52