2020 GopherCon大会PPT,一睹为快

回复

编程艺术 OS小编 发起了问题 1 人关注 0 个回复 156 次浏览 2020-11-17 11:26 来自相关话题

每日一题-TCP连接在整个生存期内有哪些状态

编程艺术 空心菜 回复了问题 2 人关注 1 个回复 216 次浏览 2020-11-17 11:16 来自相关话题

每日一题-Redis主从切换

回复

数据库 peanut 回复了问题 1 人关注 1 个回复 208 次浏览 2020-11-11 10:06 来自相关话题

每日一题-Redis主从库数据同步

回复

数据库 peanut 回复了问题 1 人关注 1 个回复 229 次浏览 2020-11-10 10:32 来自相关话题

每日一题-Redis AOF日志重写

回复

数据库 peanut 回复了问题 1 人关注 1 个回复 328 次浏览 2020-11-07 10:18 来自相关话题

未来中国的芯片产业暗藏着哪些机会?

科技前沿 星物种 发表了文章 0 个评论 170 次浏览 2020-11-06 23:45 来自相关话题

一说芯片,大家就会想到CPU。提到CPU,我们知道得最多的是两种,一种是英特尔、AMD使用的x86架构,一种是ARM架构。其实,除了这两个之外,还有那些做得不是很成功的CPU架构,我相信你绝大部分没听说过。它们有MIPS架构、Sparc架构、Power架 ...查看全部

一说芯片,大家就会想到CPU。提到CPU,我们知道得最多的是两种,一种是英特尔、AMD使用的x86架构,一种是ARM架构。其实,除了这两个之外,还有那些做得不是很成功的CPU架构,我相信你绝大部分没听说过。它们有MIPS架构、Sparc架构、Power架构和Alpha架构,还有最新出现在人们视线的RISC-V。


除了最知名的x86和ARM这两种架构,其它的架构路线可以说非常坎坷。


MIPS架构最早是由80年代初斯坦福大学研究出来的,是最早商业应用的芯片之一,但规模远不如x86和ARM。


Sparc架构是由Sun公司设计的,在微机时代 ,Sun是在硅谷唯一可以和IBM比肩的巨头,但在2010年被甲骨文收购,Sparc架构也渐渐淡出人们视线。


Power架构最早是IBM开发的,但IBM的战略是自己做系统集成,面对Intel的x86架构联合Windows联盟的竞争,IBM最后败下阵来,就没有投入更多精力继续做开发了。


Alpha架构是DEC公司开发的,后来DEC被惠普公司收购,而惠普公司产品线都集中在x86技术路线上,Alpha架构卖给了中国无锡的江南计算所,我们后面还会提到。

还有最新的RISC-V架构,据说很多国内公司包括小米、华为、阿里都砸了重金投入,但目前还没有构建出一个完整的生态出来。

接下来我们展开讲讲,采用这些不同架构技术路线的公司,哪些芯片公司做起来了,哪些公司未来有可能会失败。


一、中国的第一阶段


Mips架构



MIPS架构处理器最早是由80年代初斯坦福大学研究出来的,国内使用MIPS架构处理器的代表是龙芯中科。龙芯中科的背景来自中国科学院计算所,最早用MIPS架构搭配Linux系统,打造国产PC。龙芯中科的董事长胡伟武是中国科学院计算技术研究所研究员、总工程师,在国内的CPU研发领域是相对做得还算不错的。

另一家采用MIPS架构的是北京君正,研发的领域主要是物联网设备,不需要很强的CPU性能,而是强调价格便宜、功耗低。物联网这个领域正在兴起,参与企业非常多,所以也容易在这个市场里分到一块蛋糕。


Power架构
刚才提到的IBM研发的Power架构,2016年一家国内企业中昊宏芯从IBM买到了POWER架构的永久授权,但是研发过程并不顺利,至今都没有看到太多的应用。

Alpha架构
无锡江南计算所买下了Alpha架构所有设计资料,开发了国产Alpha处理器,此前多次夺得超算排名第一的“神威·太湖之光”,就是用的这种处理器。


其实相比移动计算,超算并不需要太先进的芯片。原因很简单,移动计算的散热、能耗要求非常苛刻,而服务器的空间很大,对体积没有太大的要求,对散热、能耗更没有太大的限制,能耗大点没关系,散热可以有单独的采用液冷技术的机柜设备。简单说就是砸巨资投入,把大量的芯片和相关设备堆砌起来,从而实现强大的算力。


另外,申威处理器也是目前唯一的Alpha架构处理器产品了,并不具备大规模应用的前景,我们普通人更是基本接触不到了。



x86架构
然后说到x86架构了。中国企业发展x86,比较难的是授权,因为x86架构一直在Intel和AMD手里。除了Intel和AMD以外,第三家拥有X86授权的公司,是台湾威盛,上海兆芯用2.57亿美元从威盛那儿买到了x86授权。上海兆芯是上海市政府控股的基金,为了生产中国的芯片,于是和台湾威盛合资,上海政府控股80%,就是冲着芯片去的。


但是这个x86授权是很残缺的,是威盛与Intel的官司之争中拿到的,授权期限在2018年4月就过期了,以后研发新的架构只能靠兆芯自己了,所以兆芯的位置很尴尬。


另外,虽然上海兆芯也推出了产品在市场上销售了,但因为没有大规模销售,没法分摊研发成本,性价比还是非常低的。


另一家拿到x86架构的是天津海光,是从AMD那儿拿到的授权,而不是Intel。为了绕开Intel,玩了一个什么游戏呢?AMD和海光先成立合资公司A,AMD是大股东,左手授权给右手。随后AMD和海光成立合资公司B,这家公司海光是大股东,然后合资公司B从合资公司A那儿拿到了授权,这样就绕开了Intel。


不过这样的做法海光处理器是十分受限的,被规定只能在中国境内销售。海光是很被动的,产品能否长期生产销售主要取决于AMD,如果AMD不同意,那海光处理器就不能继续生产了。所以这样的合作只能防住Intel,但是防不住美国封锁。


二、中国的第二阶段

上面提到的芯片架构,中国的国产化都做得不算成功,但是到ARM架构上我们能看到一些曙光了。华为海思、飞腾、展讯都是做ARM相对比较不错的。华为海思的处理器主要应用于移动端产品,手机和智能家居产品都有应用。天津飞腾最早用Sparc处理器,也就是刚才提到的Sun公司开发的,但是Sun被甲骨文收购以后,飞腾就转向ARM架构了,主要面向国家安全市场,为军队、政府服务。


这里特地要表扬的是展讯,这是一家不错的国内的采用ARM架构的公司。展讯的手机芯片主要用于低端手机,只支持GSM和GPRS两种网络制式,市场主要面向非洲、东南亚等低收入海外市场。同时展讯也有基带芯片,目前有5G基带芯片的厂商只有五家:华为、联发科、高通、三星,最后一家就是展讯。这也是中国企业未来可能去实践的一条芯片破局之路,那就是和行业深度结合。通讯就是一个很重要的行业,展讯也是从通讯行业做起来的。

三、中国的第三阶段

芯片的发展速度在加快,真正的机会在于第三阶段,那就是人工智能和云的时代。寒武纪在科研方面非常领先,陈云霁2014年就设计出了用汉语拼音命名的DianNao人工智能芯片设计架构,被认为是世界第一,要比谷歌的TPU都要早了两年。而且之前一直和他有紧密合作的法国的Olivier Temam教授14年被挖到了谷歌,谷歌研究TPU的论文里也多次引用陈云霁的论文,应该说TPU的设计里借鉴了陈云霁的思想。


但是寒武纪之所以也比较难,那是因为我们的生态还没有搭建起来。我们看见哪一个是好的芯片企业,我就拿大钱给他,结果芯片企业的心态就是:我不能合作,如果我扶植一帮合作伙伴起来,这个补贴的钱就分流了,而我越说自己什么都干就越拿更多的钱。最终就导致了“竖井式结构”:比如华为抛弃了寒武纪,从芯片设计到生产、应用全都自己做,阿里巴巴本来是需求方,做云计算需要大量芯片,结果也是从研发到生产大包大揽。这跟全世界的发展趋势是背道而驰的。


四、总结

前面我们讲了那么多芯片,你会发现,有不少今天不那么普及的芯片架构,都是一些边边角角的不重要的技术领域。一家芯片企业如果没有选中未来的主流技术,很有可能会被淘汰掉,因为你的做法不是未来有最大机会的方向,这家企业再怎么优秀都没有用。


芯片的发展是两条路线,一条是通用芯片,覆盖所有人。这条路要跟上时代,现在的机会就是人工智能+云计算,这方面的赢家是NVIDIA。中国曾经本来有机会,但是很可惜没有把握住。但是另一条路是我们未来可以把握住的,那就是与行业深度结合的专用芯片。


所谓专用芯片,就是在行业里深挖,借助自己的行业优势来培养自己的芯片优势。像欧洲依托行业配置出了英飞凌、意法半导体、恩智浦这样的芯片公司,在汽车电子、工业制造、传感器有着很深的应用。而中国未来的行业机会,我认为有三个:无线通讯、无人驾驶和物联网


在无线通讯领域,已经有比较优秀的公司,就是刚才介绍的做5G基带芯片的展讯。


在无人驾驶领域,因为未来电动车都会上自动驾驶,以后越来越多会出现封闭路面的自动驾驶、货运车、还有小型的送货车,自动驾驶的芯片的需求越来越大。这方面我觉得有机会的是地平线。我开玩笑说,高端是负责管吆喝的,低端是负责赚钱的,地平线的芯片虽然没那么高端,但是性价比更高,接地气的战略可能会有更大的优势。


最后,物联网领域给我们留下了一个悬念。这个领域的差异化很大,比如未来这个领域需要很多相对低端的芯片,性能参差不齐,也需要所谓叫模拟转数字的芯片,大量的模拟芯片会有应用空间。这个领域还有一定的不确定性,中国有可能会有胜出的机会。


对于中国芯片企业的发展,我的建议是要在正确的方向上两条腿走路:首先是持续的研发投入,然后是不断巩固生态


芯片战争不是一个瞬间能决定胜负的东西,像Intel和AMD打了这么多年,因为科技领域的用户没有品牌忠诚度,比的是性能好坏而不是品牌,如果Intel过去三十年不努力做研发,“Intel Inside”的标志就没有那么大的作用。所以持续研发投入是个必要条件。


另一方面来讲,凭什么能在研发上有持续投入?因为你在市场上能够持续获得高额回报,而巩固市场的核心是要巩固生态,你要能够和一堆的合作伙伴一起去开发更多的应用,这个市场才能繁荣起来。这是中国的短板,也是未来四十年中国必须要面对和解决的问题。


分享阅读原文:http://m6z.cn/6d7clf

Prometheus配置文件热加载

智慧运维 push 发表了文章 0 个评论 279 次浏览 2020-11-05 16:36 来自相关话题

Promtheus的TSDB时序数据库在存储了大量的数据后,每次重启Prometheus进程的时间会越来越慢, 而且日常运维工作中会经常调整Prometheus的配置文件信息,比如一些静态配置,实际上Prometheus提供了在运行时热加载配置信息的功能 ...查看全部

Promtheus的TSDB时序数据库在存储了大量的数据后,每次重启Prometheus进程的时间会越来越慢, 而且日常运维工作中会经常调整Prometheus的配置文件信息,比如一些静态配置,实际上Prometheus提供了在运行时热加载配置信息的功能,在这里介绍一下。


Prometheus配置热加载提供了2种方法:


  1. kill -HUP pid 发送SIGHUP信号方法
  2. 通过Prometheus服务API接口,发送发送一个POST请求到/-/reload

Tips: 从 Prometheus2.0 开始,热加载功能是默认关闭的,如需开启,需要在启动 Prometheus 的时候,添加 --web.enable-lifecycle 参数。



我个人更倾向于采用curl -XPOST http://localhost:9090/-/reload 的方式,因为每次reload过后, pid会改变,使用kill方式需要找到当前进程号。


如果配置热加载成功,Prometheus会打印出下面的log:


... msg="Loading configuration file" filename=prometheus.yml ...

下面我们来看看这两种方式内部实现原理。


第一种方法: 通过 kill 命令的 HUP (hang up) 参数实现
首先Prometheus在 cmd/promethteus/main.go 中实现了对进程系统调用监听,如果收到syscall.SIGHUP信号,将执行reloadConfig函数。


代码类似如下:


{
// Reload handler.

// Make sure that sighup handler is registered with a redirect to the channel before the potentially
// long and synchronous tsdb init.
hup := make(chan os.Signal, 1)
signal.Notify(hup, syscall.SIGHUP)
cancel := make(chan struct{})
g.Add(
func() error {
<-reloadReady.C

for {
select {
case <-hup:
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
}
case rc := <-webHandler.Reload():
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
rc <- err
} else {
rc <- nil
}
case <-cancel:
return nil
}
}

},
func(err error) {
// Wait for any in-progress reloads to complete to avoid
// reloading things after they have been shutdown.
cancel <- struct{}{}
},
)
}

第二种:通过 web 模块的 /-/reload请求实现:


首先 Prometheus 在 web(web/web.go) 模块中注册了一个 POST 的 http 请求 /-/reload, 它的 handler 是 web.reload 函数,该函数主要向 web.reloadCh chan 里面发送一个 error。


其次在Prometheus 的cmd/promethteus/main.go中有个单独的 goroutine 来监听web.reloadCh,当接受到新值的时候会执行 reloadConfig 函数。


func() error {
<-reloadReady.C

for {
select {
case <-hup:
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
}
case rc := <-webHandler.Reload():
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
rc <- err
} else {
rc <- nil
}
case <-cancel:
return nil
}
}

},

Prometheus内部提供了成熟的hot reload方案,这大大方便配置文件的修改和重新加载,在Prometheus生态中,很多Exporter也采用类似约定的实现方式。

每日一题-redis数据持久化

数据库 peanut 回复了问题 2 人关注 2 个回复 225 次浏览 2020-11-05 14:36 来自相关话题

每日一题-Redis 为什么那么快?

编程艺术 空心菜 回复了问题 3 人关注 2 个回复 202 次浏览 2020-11-05 10:34 来自相关话题

企业不同时期的运维规划

智慧运维 OS小编 发表了文章 0 个评论 216 次浏览 2020-11-02 22:32 来自相关话题

企业创业期企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要 ...查看全部

企业创业期

企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要的操作标准、流程机制,比如业务目录环境都是各式各样的。在这个阶段建议建立如下规范:


  • 统一权限管理:应用程序、操作员、管理员权限分离。
  • 制定完善的操作流程:先开发环境验证、测试环境验证、预生产环境、生产环境的基础操作流程,最小操作权限、最小化的目录权限为准则。
  • 制定代码发布流程和机制:以开发环境、测试环境发布为先,在预生产环境、生产环境发布制定相应的审核。
  • 制定代码编写规范:制定排版、注释、标识命名、异常处理等相关规范,避免出现个性化的代码。
  • 使用云商自有监控做基础监控,主要是cpu、内存、网络等。
  • 强化系统、业务基线安全。


企业高速发展期

在企业发展期,拿到融资后,业务快速发展,随着服务器规模、系统复杂度的增加,全人工的操作方式已经不能满足业务的快速发展需要。因此,运维人员逐渐开始使用批量化的操作工具,针对不同操作类型出现了不同的脚本程序。


但各团队都有自己的工具,每次操作需求发生变化时都需要调整工具。这主要是因为对于环境、操作的规范不够,导致可程序化处理能力较弱。此时,虽然效率提升了一部分,但很快又遇到了瓶颈。在这个阶段建议建立如下规范:


  • 制定运维相关脚本的编写标准:如统一相关备份空间、相关备份执行计划,制定相关脚本的执行人员、执行权限、执行时间。
  • 统一同类工具的使用:如数据连接工具、备份工具、数据同步工具等。
  • 确认相关的操作人,减少或者避免开发和测试在服务器上的相关操作。
  • 部署监控平台进一步的监管数据库、进程、日志等。
  • 使用第三方应用性能管理对应用性能做应用分析和优化。


企业稳定发展时期

在企业稳定期,在这个阶段,对于运维效率和误操作率有了更高的要求,我们决定开始建设运维平台,通过平台承载标准、流程,进而解放人力和提高质量。
这个时候对服务的变更动作进行了抽象,形成了操作方法、服务目录环境、服务运行方式等统一的标准。通过平台来约束操作流程。

在平台中强制需要运维人员填写相应的检查项,然后才可以继续执行后续的部署动作。在这个阶段建议建立如下运维平台:


  • 统一运维操作和管理平台:操作管理、权限管理、资源。
  • 统一日志平台:统一日志收集标准、日志收集接口,查询方式,查询授权。
  • 统一监控平台:强化监控,从系统、数据库、缓存、中间件、接口、业务性能等。
  • 统一发布平台:细化发布项目、发布权限、发布审核、回滚、备份等。
  • 加强安全防护:上线前做安全加固、安全评估、渗透测试等。
  • 统一开发规范:统一接口、数据库、配置文件等规范。


企业集团化、规模化发展时期

更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立,原有的将批量操作转化成平台操作的方式已经不再适合,需要对服务变更进行更高一层的抽象。比如智能告警、故障自愈、运营辅助决策等。


这个阶段需要大量的运维数据支持,做相应的数据分析、测试,才能使用,不然因误报或错误的故障自愈决策造成大规模的故障。


分享阅读原文: http://m6z.cn/6sGPLO