• 小白搞懂了GC全过程,全靠阿里专家12张图

    垃圾回收全过程

    架构师社区 GC JVM 阿里

  • 35岁老码农:老板,你看我还有机会吗?

    最终,老张还是被干掉了。休息一个月后,老张开始了漫长的找工作之路。由于老张年纪太大,技术也不算精深,过了半年也没找到工作。迫于生计,不得不转行。先后送过外卖,开过滴滴,甚至还卖过鸡蛋灌饼。不过收入就差很多了,除去每月房贷和全家生活费就所剩无几了。 你们都去哪了? 老程序员都去哪了?互联网行业以及新兴领域的更新迭代速度很快,需要不断补充新鲜血液、新思维、新技术,在人才方面呈现出年轻化态势。大部分程序员年龄集中在23岁~30岁。35岁以上的老程序员越来越少,主要两方面的原因:其一,随着经验的积累和能力的提高,一部分程序员转成架构师或者管理岗;其二,一部分程序员被裁员后找不到工作被迫转行。 为什么很多老程序员被迫转行? 上面已经提到了,一些老程序员被裁后找不到工作,所以被迫转行。但是为什么会有这么多人找不到工作呢? 首先,大部分老员工经历过多年工作生涯,在职场的打磨中,会变得越来越圆滑,越来越事故。在工作热情和积极主动性上,比初入职场的年轻人要差很多。 其次,一般情况下老员工的工资比新员工要高很多。如果老员工在工作上没有明显能力优势,却拿着比新人高一两倍的工资,如果你是老板,你会怎么做! 还有,在IT行业对老程序员的歧视是普遍现象。大家普遍认为,写了10几年代码都没干成架构师或者被提拔成管理岗,肯定是能力有问题! 程序员只是一碗青春饭? 有人说,程序员就像职业球员一样,靠青春吃饭,年纪大了自然会被市场淘汰!像球员一样不得不提前退役。 笔者已近不惑之年,从过往16年的职场经历来看。不管从事什么行业什么岗位,如果不一直保持进步,到35岁之后被裁员并且找不到工作的人确实挺多。很多真实的例子发生在周围的同事和朋友身上,让人感觉到市场的冷酷和无情。其实,市场真正会淘汰掉的,不是年纪大的人,而是年纪大但没本事的人,还有那些年纪大失去工作热情的人。 21世纪最缺的就是人才,软件行业互联网行业如此,其他各行各业也都是如此。真正的高手程序员,不管从技术能力、经验还是效率上确实能甩开初级程序员十条街。有人说:我还是高级程序员呢,现在还不是被裁,找不到工作!不妨扪心自问,你是高级程序员的头衔,你真的有高级程序员的能力吗?你会写shell脚本吗,你了解内存栅栏吗,你对内存模型有多少研究,你看过多少源码,你对IO到底了解多少,你对操作系统有研究吗,你和周围的年轻人相比有没有明显的优势? 程序高手绝不简单,需要长期的积淀,需要经过日积月累的努力工作和学习,才能写出真正的程序,构成一套属于自己的技能体系,换句话来说就是,程序员这行想混好,不但要努力工作还要好好钻研技术、多掌握别人不懂的核心技术、把技术搞透搞深、不断提高自己的能力,做好自己的职业规划。有了核心竞争力,别说35,哪怕是45、55岁,你仍然是稀缺资源,仍然会是市场逐鹿的对象。所以说,关键不是年龄的问题而是人的问题,年龄到了35岁,技术却没到35岁,又拿着比年轻人高两三倍的工资,老板不裁你裁谁?市场不抛弃你才怪! 培养核心竞争力 所谓核心竞争力,就是和其他人相比,你具备哪些明显优势!比如,你的技术能力明显比其他人强,别人解决不了的系统问题,你能解决;比如,你的沟通能力很强,别人谈不妥的事,你能谈妥。其实也就是随着工作经验积累和不断学习带来的自身能力的提升。 IT行业是一个需要不断进步的行业,作为IT从业人员也要不断学习,保持知识的快速更新和能力的持续提高,这样才能与时俱进,保持自己的鲜活性,提高核心竞争力。 不要一直待在舒适区!在工作中,如果你感觉自己很长时间都待得很舒服,感觉很安逸。那就危险了,说明你停滞不前了,长此以往你的年龄和能力将不成正比。随着时间推移,很可能会被公司和市场淘汰。所以这时需要勇敢地跳出舒适区,如果你在公司确实已经学不到什么了,那就换家公司;否则就换一种工作方式,每天学习新知识,主动找活儿干,让自己忙起来,让自己每天有新的收获。 从人的本性来说,我们是不愿意离开“舒适区”的,这意味着我们需要放弃,甚至需要自我归零,再从零起步;其次,当我们进入“陌生区”之后,必然会面临很多不确定因素,而不确定性正是我们所避之不及的。走出舒适区,总会经历一个痛苦的过渡期。不过,一旦度过过渡期,我们将完成职业生涯甚至是人生的一次蜕变。 人的平均寿命达到百岁即将成为现实。对于刚刚30多岁,人生路程刚走过三分之一的我们而言,不能在人生的上半场都还没有结束的时候就放弃了,我们还有很多机会去开启第二个人生! 曾任职于阿里巴巴,每日优鲜等互联网公司,任技术总监,15年电商互联网经历,擅长高并发场景下系统性能和稳定性解决方案

    架构师社区 互联网 程序员 码农

  • MySQL索引底层:B+树详解

    树的简介 树跟数组、链表、堆栈一样,是一种数据结构。它由有限个节点,组成具有层次关系的集合。因为它看起来像一棵树,所以得其名。一颗普通的树如下: 树是包含n(n为整数,大于0)个结点, n-1条边的有穷集,它有以下特点: 每个结点或者无子结点或者只有有限个子结点; 有一个特殊的结点,它没有父结点,称为根结点; 每一个非根节点有且只有一个父节点; 树里面没有环路 一些有关于树的概念: 结点的度:一个结点含有的子结点个数称为该结点的度; 树的度:一棵树中,最大结点的度称为树的度; 父结点:若一个结点含有子结点,则这个结点称为其子结点的父结点; 深度:对于任意结点n,n的深度为从根到n的唯一路径长,根结点的深度为0; 高度:对于任意结点n,n的高度为从n到一片树叶的最长路径长,所有树叶的高度为0; B-树 简介 B-树,也称为B树,是一种平衡的多叉树(可以对比一下平衡二叉查找树),它比较适用于对外查找。看下这几个概念哈: 阶数:一个节点最多有多少个孩子节点。(一般用字母m表示) 关键字:节点上的数值就是关键字 度:一个节点拥有的子节点的数量。 一颗m阶的B-树,有以下特征: 根结点至少有两个子女; 每个非根节点所包含的关键字个数 j 满足:⌈m/2⌉ - 1 <= j <= m - 1.(⌈⌉表示向上取整) 有k个关键字(关键字按递增次序排列)的非叶结点恰好有k+1个孩子。 所有的叶子结点都位于同一层。 一棵简单的B-树如下: B+树的查找 因为B+树的数据都是在叶子节点上的,内部节点只是指针索引的作用,因此,查找过程需要搜索到叶子节点上。还是以这颗B+树为例吧: B+树的删除 B+树删除关键字,分这几种情况 找到包含关键值的结点,如果关键字个数大于⌈m/2⌉-1,直接删除即可; 找到包含关键值的结点,如果关键字个数大于⌈m/2⌉-1,并且关键值是当前节点的最大(小)值,并且该关键值存在父子节点中,那么删除该关键字,同时需要相应调整父节点的值。 找到包含关键值的结点,如果删除该关键字后,关键字个数小于⌈m/2⌉,并且其兄弟结点有多余的关键字,则从其兄弟结点借用关键字 找到包含关键值的结点,如果删除该关键字后,关键字个数小于⌈m/2⌉,并且其兄弟结点没有多余的关键字,则与兄弟结点合并。 如果删除该关键字后,关键字个数小于⌈m/2⌉-1,兄弟节点可以借用 以下这颗5阶的B+树, 如果删除15,删除关键字的结点只剩1个关键字,小于⌈5/2⌉-1=2,不满足B+树特点,但是其兄弟节点拥有3个元素(7,8,9),可以借用9过来,如图: InnoDB一棵B+树可以存放多少行数据? 这个问题的简单回答是:约2千万行。 在计算机中,磁盘存储数据最小单元是扇区,一个扇区的大小是512字节。 文件系统中,最小单位是块,一个块大小就是4k; InnoDB存储引擎最小储存单元是页,一页大小就是16k。 因为B+树叶子存的是数据,内部节点存的是键值+指针。索引组织表通过非叶子节点的二分查找法以及指针确定数据在哪个页中,进而再去数据页中找到需要的数据; 假设B+树的高度为2的话,即有一个根结点和若干个叶子结点。这棵B+树的存放总记录数为=根结点指针数*单个叶子节点记录行数。 如果一行记录的数据大小为1k,那么单个叶子节点可以存的记录数 =16k/1k =16. 非叶子节点内存放多少指针呢?我们假设主键ID为bigint类型,长度为8字节,而指针大小在InnoDB源码中设置为6字节,所以就是8+6=14字节,16k/14B =16*1024B/14B = 1170 因此,一棵高度为2的B+树,能存放1170 * 16=18720条这样的数据记录。同理一棵高度为3的B+树,能存放1170 *1170 *16 =21902400,也就是说,可以存放两千万左右的记录。B+树高度一般为1-3层,已经满足千万级别的数据存储。 参考与感谢 B+树看这一篇就够了 [1] B树和B+树的插入、删除图文详解 [2] InnoDB一棵B+树可以存放多少行数据? [3] Reference [1] B+树看这一篇就够了: https://zhuanlan.zhihu.com/p/149287061 [2] B树和B+树的插入、删除图文详解: https://www.cnblogs.com/nullzx/p/8729425.html [3] InnoDB一棵B+树可以存放多少行数据?: https://www.cnblogs.com/leefreeman/p/8315844.html

    架构师社区 索引 MySQL B树

  • ZLG面向体外诊断设备嵌入式解决方案

    ZLG面向体外诊断设备嵌入式解决方案

    摘要:ZLG深耕嵌入式二十年,为诸多医疗企业用户提供嵌入式解决方案,包括基因扩增仪、荧光免疫分析仪、特定蛋白分析仪等常用医疗设备,本篇文章为大家介绍ZLG在体外诊断设备上提供的各类嵌入式解决方案。 病毒试剂盒的研制离不开基因扩增仪(PCR)、荧光分析仪等医疗仪器的分析,试剂研制成功之后,需要对疑似病患的鼻咽拭纸、痰液、肺泡灌洗液3种样本进行检测。而试剂盒的检测同样需要相应的仪器配套工作,其中包括特定蛋白分析仪、手持式荧光分析等医疗设备,在大范围的检测群体需求下会对此类设备有小型化需求,最优情况下是实现手持式分析,实现即时检验(PCOT)。 ZLG成熟的应用方案已在此类设备仪器中广泛应用。本文将为大家介绍ZLG在设备仪器中的方案。 一、基因扩增仪 基因扩增仪(PCR)实际上是一种可编程控制的、可快速变温的、可精密控温的温度循环仪,主要用于基因分离、克隆和核酸序列分析等研究,因其灵敏度高、操作简单、省时等特点,在此次新冠状病毒的全基因组序列获取中发挥至关重要的作用。 基因扩增仪(PCR)系统框图大致如下所示,主要包括显示通讯控制板、控制系统主控板和电源。ZLG为基因扩增仪主要提供Cortex-A7平台显控方案——M6Y2C,工业控制核心板,并通过严格EMC和高低温测试,确保核心板在严酷的环境下稳定保证显示的稳定与可靠。 系列平台具备如下优势: · 配置了工业级超大容量eMMC与TF卡; · 丰富的接口资源,包含以太网、RS-485、CAN等通讯接口; · 拥有丰富的接口资源,包括8路UART,2路隔离CAN-bus,1路隔离RS-485,1路USB Host等多种有线数据通讯接口。 二、手持/台式荧光分析仪 荧光免疫分析仪用于医院体外检测,主要对人体的血清/血浆/全血/尿液样本进行检测,辅助诊断人的心肌损伤,心力衰竭,急性冠状动脉综合征,心血管炎症,静脉血栓栓塞,常规炎症,细菌/病毒感染的鉴别,急慢性肾病等疾病的早期发现及治疗。 荧光分析仪主要包括两种控制平台:PC电脑、ARM主控。 ZLG为荧光分析仪PC电脑平台提供USBCAN采集卡方案,主要用于实现PC与荧光分析仪链接,进行数据交互,控制控制电机、光源等,具体如下所示: ZLG为荧光分析仪ARM平台提供系列解决方案,经过二十多年的嵌入式积累,提供推出了稳定可靠的Cortex-A7解决方案,具体如下所示。 系列平台具备如下优势: · 预留丰富的扩展接口; · 提供WIFI、4G、ZigBee等无线方案的选择,可根据实际情况通过MiniPcie进行扩展; · 核心板结构利于将台式和便携式仪器统一到同一个平台,同一套底板,节省开发周期; · 提供了周到的技术支持以及详细的技术开发资料,缩短开发、生产周期。 三、特定蛋白分析仪 特定蛋白分析仪主要用于检测血清、血浆和尿液中的特定蛋白浓度检测,原理是基于免疫比浊法基础,从结构上主要分为透射比浊和散射比浊两种,可以检测包括血浆或血清、尿液、脑脊液等样本中特定蛋白的浓度。 ZLG为特定蛋白分析仪提供Cortex-A9平台主控方案,小巧的体积符合诊断设备小型化、便携化需求。 系列平台具备如下优势: · 丰富接口、强劲性能、设计更灵活; · 丰富的多媒体接口,支持摄像头、HDMI、LCD、LVDS接口,轻松实现图像采集和媒体显示; · 强大的编解码功能,集成了1080P视频编解码等强大的多媒体编解码功能。

    致远电子 嵌入式 ZLG 体外诊断设备

  • Microchip宣布推出基于COTS的宇航级抗辐射电源转换器

    Microchip宣布推出基于COTS的宇航级抗辐射电源转换器

    随着人们对通信和气象卫星的依赖程度越来越高,太空研究的范围和任务也在不断扩大,需要新技术来帮助加快航天系统的设计和生产。Microchip Technology Inc.(美国微芯科技公司)今日宣布扩大 SA50-120 电源转换器系列产品阵容,推出九款基于商业级现货技术(COTS)的新产品, 为开发人员提供宇航级电源转换器,帮助最大限度地降低风险和开发成本。 Microchip的SA50-120抗辐射DC-DC电源转换器是目前市场上仅有的标准非混合型宇航级DC-DC电源转换器,采用表面贴装元件结构,可根据特定应用和要求进行灵活定制。SA50-120系列符合Mil-Std-461、Mil-Std-883和Mil-Std-202标准,使设计人员能够从成熟的COTS技术开始,迅速扩大开发规模,降低风险,缩短开发时间。 SA50-120 电源转换器采用120V输入,并在低端小型解决方案中提供高达 56W的输出。这些具有单输出和三输出的电磁干扰(EMI)兼容和抗辐射设计是空间站和ORION计划平台的理想选择。新推出的电源转换器采用开关稳压器,使用峰值电流模式控制的单端正向转换器拓扑结构,具备固有的单事件抗扰度。SA50-120具有800万小时平均无故障时间(MTBF)和高达87%的效率,在所有标准120V输入的宇航级DC-DC电源转换器中最高,可最大限度地提高系统性能和可靠性。新产品符合100 krad (Si)总电离剂量(TID)和单次事件效应(SEE)大于80 MeV cm2/mg的要求,并提供同步、晶体管-晶体管逻辑(TTL)开/关指令信号和各种保护功能。单输出版本还提供远程感应、输出电压调节和并联功能。 Microchip分立式产品部副总裁Leon Gross表示:“Microchip作为航天技术合作伙伴已有30年历史,成功参与了50多个项目和平台,我们将继续投资开发航空航天系统所需的关键技术。” Microchip的DC-DC电源转换器技术以及经ISO 9000和AS9100认证的生产设施,可提供高质量的装置以及灵活的制造选择。 在推出基于COTS技术的新产品的同时,Microchip还与系统制造商和集成商合作进行老化管理,支持客户努力减少重新设计工作,延长生命周期,从而降低整体系统成本。 该款DC-DC电源转换器补充了Microchip丰富的空间产品组合,包括抗辐射和耐辐射的现场可编程门阵列(FPGA)、单片机(MCU)、微处理器(MPU)、时序产品、半导体和负载点调节器,以及高可靠性机电、任务关键型和宇航级继电器,为设计人员提供各种应用的整体系统解决方案。 开发工具 Microchip 提供端到端设计支持,以加快产品上市,包括分析、鉴定和生产。设计人员可以根据需求获得大量的分析和鉴定报告。同时,Microchip还提供工程开发单元。 供货与定价 Microchip 的 SA50-120S 器件提供 3.3V、5V、12V、15V 和 28V 输出。SA50-120T 器件提供 3.3V 或 5V 主输出和 12V 或 15V 辅助输出。这些抗辐射器件现已批量生产和提供限量样品试用。如需了解更多信息,请联系Microchip销售代表、全球授权经销商或访问Microchip网站。

    Microchip Microchip 电源转换器 COTS

  • 第二代屏下摄像头技术横空出世!真正的全面屏手机来啦!

    第二代屏下摄像头技术横空出世!真正的全面屏手机来啦!

    经过多年的发展演变,目前全面屏手机的正面摄像头形态基本确定,大部分不是开孔屏就是刘海屏,当然,对于手机屏幕正面的那颗无处安放的前置摄像头,手机品牌也是想尽各种办法要抹除它,以追求极致的全面屏美感。屏下摄像头手机,前置摄像头完全内置在屏幕之下,屏幕不再是刘海屏或滴水屏,是真正的全面屏手机。 随着技术进步和消费者对大屏手机的需求增加,手机厂商一直致力于提高手机的屏占比,从所谓的无边框手机到刘海屏,再到水滴屏和升降摄像头的设计,以及折叠屏的推出,手机向真全面屏的发展可谓百战不殆。而屏下摄像被认为是真全面屏的终极解决方案。与刘海屏、滴水屏相比,将前置摄像头放在屏幕内层并不困难,困难的是如何解决透光问题——在实现全面屏的同时,让前置摄像头的自拍、人脸识别等功能不受影响成为关键。 全面屏设计已经从刘海屏发展到了现在的挖孔屏,虽然挖的孔很小且已经不影响屏幕显示了,但对于很多网友来说,还是期待完美无缺的全面屏,因此屏下摄像头就成为了全面屏的终极方案。说到屏下摄像头,目前共有两家手机厂商有明显的动作,包括小米和中兴,其中中兴更是直接量产屏下摄像头手机。 由于全面屏是大趋势,所以为了提升屏占比,安卓厂商大都放弃了3D结构光人脸识别,目前仅有苹果iPhone还在坚持,但要想有3D结构光,就必须要接受大刘海屏,而中兴首发屏下3D结构光将会解决大刘海屏的问题!还有,3D结构光现在已经不是最好的生物解锁了,因为出门戴口罩时3D结构光就是个摆设。 虽然早在2019年的时候,小米、OPPO两家公司就已经公布了自家的屏下摄像头技术,但是直到现如今,这两家公司依旧没有实现屏下摄像头技术的量产,而曾经位列于“中华酷联”国产手机四大天王的中兴手机,却在2020年9月1日,正式发布了全球首款能够真正量产的屏下摄像手机——中兴天机Axon 20 5G。 中兴曾在其上一代Axon 20系列上全球首发了量产屏下摄像头技术,当时吸引了不少关注。而前段时间,中兴也正式宣布了Axon 30 Pro,相比上代搭载的是骁龙765G中端处理器,这次的Axon 30 Pro搭载了骁龙888处理器,定位也从中端机型升级为旗舰机型。 值得注意的是,中兴天机AXON 20 5G虽然是全球首款配备屏下摄像头的智能手机,但是搭载的第一代量产屏下摄像头技术。 这也意味着第二代屏下摄像头相对于第一代产品要成熟很多,比如开孔更小,隐藏更深,自拍效果优化更好等等,当然,最为关注的就是屏下3D结构光技术了。毕竟3D结构光技术对于人脸识别的准确性,安全性会有更好的体验,也更为实用。目前手机行业也仅有苹果、华为等品牌在坚持,中兴此次发布的屏下3D结构光技术或许会掀起新一轮3D结构光的技术发展。 屏下3D结构光技术则更加让人期待,可以让手机产品在摆脱刘海实现真全面屏的同时实现3D人脸识别,这样也就可以支持人脸支付了。不过与屏下摄像头相比,其难度则更加大,因为穿过屏幕的组件会更多,而且对于安全性的要求会更高,实际表现如何还得等到中兴在MWC2021上海展会上进行揭晓。

    单片机 摄像头 屏下摄像头

  • 华为智慧养猪方案引业界哗然,能否发挥5G技术领先优势?

    华为智慧养猪方案引业界哗然,能否发挥5G技术领先优势?

    众所周知,华为第一大业务--手机业务萎缩已是必然,为此它正积极拓展新业务。生猪养殖业真香,连电信巨头华为都想进去分一杯羹了。近日,华为机器视觉领域总裁段爱国在微头条爆料称,华为机器视觉推出了智慧养猪方案。养殖业的发展方向是数字化、智能化和无人化。近年来,猪宝宝的身价一波三折,从原来的7~15元每斤,直愣愣地涨到了20~40元每斤。 华为的这则新闻,引起了很多业界人士的注意:推出智慧养猪计划。众所周知,华为通过近40年的努力已积累了雄厚的技术优势,在5G、云计算、芯片等方面都打下了扎实的基础,智慧养猪方案正是它试图集合这项技术推出的新业务。 一项新技术除了要有足够的技术优势之外,还需要考虑成本问题,在以往的诸多案例中都说明了成本对技术推广的决定性影响,而华为在5G技术上的核心技术优势毫无疑问,影响华为智慧养猪方案的主要还是成本问题。 目前,华为所依赖的“全球供应链系统”遭到了挑战,但华为官方此前披露的数据,2020年前三季度,华为实现销售收入6713亿元人民币,同比增长9.9%,净利润率8.0%。 5G网络建设的成本极为昂贵,正是由于建网成本高昂,导致当前的5G流量价格难以下降,以致于当下的5G用户发展进度远低于当年的4G,对于华为结合5G技术的智慧养猪方案,成本恰恰是它的最大问题。 华为云将成为“智慧养猪”解决方案架构重要组成部分。 据了解,这套养猪系统提供仪表盘监控、大数据分析、数字化管理,支持AI识别、AI学习、AI预测、AI决策等等,还通过标准化、程序化,实现全感知监控、机器人巡检和自动/远程控制。华为此次智慧养猪方案,是国家农业部的战略协议之一,后续华为还将利用自己的技术在其它领域展开智慧养殖,为养殖业带来新的变革。 网易在互联网养猪方面更是走在前面,网易是国内科技企业中最先介入养猪业的企业,在理论与实际结合方面走在华为前面。华为认为,未来数据是现代养猪的核心要素,更是养猪智能升级的核心驱动力。从以前以“人管”为主到未来以“数据管”猪场为主,在数据管理猪场的过程中再运用AI技术做更多的科学决策,从而实现养猪的标准化和程序化。 可以说撇开5G技术的话,华为的智慧养猪方案并无太大的技术领先优势,阿里巴巴、网易等各有自己的技术优势,华为要在养猪业推广它的应用技术并不容易。 华为希望结合工业无线控制网络、工业光环网、云计算等ICT技术与煤炭技术,帮助煤炭行业进行数字化、智能化转型,实现“少人、安全、增效”的生产模式,让煤矿工人可以“穿西装打领带”地工作。同时,实验室还将为全球矿业智能化发展探索方向。 此前,任正非表示,“如果我考不上大学,养猪可能也是养猪状元。我认为自己做什么事都很认真,无论哪件事都可以做好。”大佬们对“养猪”的热情不减,前有丁磊、马云、刘强东,如今再有任正非!小伙伴们,你们如何看待大佬们纷纷入手养猪事业呢?

    单片机 华为 智慧养猪.5G

  • 中国毫米波芯片再创辉煌,美院士:中国科学家不睡觉吗

    中国毫米波芯片再创辉煌,美院士:中国科学家不睡觉吗

    2020年5月,美方为了遏制华为的发展,利用其在半导体领域的技术优势,强行修改规则,颁发“芯片禁令”,切断华为芯片来源,让华为瞬间陷入无芯可用的尴尬处境,很多业务的发展被迫停止。危机,危中有机!美方在半导体领域的所作所为,虽然给国内高新企业的发展造成了一定的影响,但也在某种程度上促进了我国半导体行业的快速崛起。 为了弥补国内半导体行业的短板,2020年8月,国务院正式下达铁令,要求在2025年底实现70%的芯片自给率,并且为了实现这一目标,国家不但出台了大量的政策予以倾斜,并且还做了很多大事。 我国作为芯片大国,在现代科技的推动下,芯片进口量依旧稳居前列,高达3800亿美元,虽说我国进口了大量的芯片,但受到国际上某些国家新规的影响,对我国的芯片进步还是造成了一定的损失。在此基础上,我国也逐渐认识到了国产芯片的重要性,扶持芯片行业的政策不断出台,使得芯片投资的热度也居高不下。 国内扶持芯片行业的政策不断出台,芯片行业的投资热度也持续提升,芯片行业在中国已然走向舞台中央。刚刚,市场再传好消息,中国国产高性能毫米波芯片发布,并刷新全球纪录。 缺芯少魂”是我国互联网领域最大的“命门”。毫米波芯片是高容量5G移动通信核心,长期被国外垄断,是我国短板中的短板。毫米波是指波长在毫米数目级的电磁波,其频率大约在30GHz-300GHz之间。 根据通讯原理,无线通讯的最大信号带宽大约是载波频率的5%左右,因此载波频率越高,可实现的信号带宽也越大。在毫米波频段中,28GHz频段和60GHz频段是最有但愿使用在5G的两个频段。28GHz频段的可用频谱带宽可达1GHz,而60GHz频段每个信道的可用信号带宽则到了2GHz(整个9GHz的可用频谱分成了四个信道)。 比拟而言,4G-LTE频段最高频率的载波在2GHz上下,而可用频谱带宽只有100MHz。因此,假如使用毫米波频段,频谱带宽轻轻松松就翻了10倍。 将以上专业知识简朴来说,毫米波通讯频谱资源丰硕,5G时代选择使用毫米波频段,速度就比如单车道进级为十车道,传输速率得到巨大晋升。 在第六十八届国际固态电路会议上,中国电科38所发布了一款高性能77兆赫兹毫米波芯片及模组,在国际上首次实现两颗3发4收毫米波芯片及10路毫米波天线单封装集成,探测距离达38.5米,刷新了当前全球毫米波封装天线最远探测距离的纪录。 据介绍,这款芯片在24mm×24mm空间里实现了多路毫米波雷达收发前端的功能,创造性地提出一种动态可调快速宽带chirp信号产生方法,并在封装内采用多馈入天线技术,大幅提升了封装天线的有效辐射距离。同时,该芯片面向智能驾驶领域对核心毫米波传感器需求,采用低成本CMOS工艺,单片集成3个发射通道、4个接收通道,主要性能指标达到国际先进水平。 下一步,中国电科38所将进一步优化毫米波雷达芯片,根据具体应用场景提供一站式解决方案。 中国发布高性能毫米波芯片,创下全球新纪录 如今智能驾驶行业也是大势,未来的发展前景也是十分可观的,如果我国的最新芯能够满足智能驾驶领域催核心毫米波传感器的要求,对于我国的芯片技术而言,是个十足的突破。在毫米波雷达芯片成功发布后,我国相关研究部门将对该芯片实行进一步的优化,最终运用到实际中。 国际固态电路会议由发明晶体管的贝尔实验室等机构在1953年发起,被誉为集成电路行业的“奥林匹克盛会”,对于集成电路行业的技术普及和应用起到巨大推广作用。中国高性能毫米波芯片在这个场合发布,这意味着该芯片技术达到行业应用先进水平。 据报道,在毫米波雷达芯片成功发布后,接下来中国电科38所将对芯片进一步优化,实现具体场景的应用。 芯片国产化加速!遭新规反噬,美企要求“自救” 不得不说,随着国产芯片替代浪潮加速兴起,我国在芯片领域还将取得更多突破。去年8月,我国专门出台扶持芯片行业的政策,涵盖全产业链条,先进技术企业可获长达10年的免税,扶持力度世所罕见。 我们都知道,天线作为无线系统中的重要部件,有集成和分离两种形式。分离天线早已经被我们熟知,集成天线主要包括片上天线(AoC)和封装天线(AiP)两种类型。片上天线技术主要是利用半导体材料与工艺,将天线与其他的电路在同一个芯片上集成。因为有对性能和成本方面的考虑,片上天线技术在太赫兹频段上更为适用。封装天线技术主要是利用封装材料与工艺,将天线在携带芯片的封装内集成。 今年2月11日,包括英特尔、AMD、高通和美光等在内的一批美国芯片制造企业,又致信给美国政府,要求后者提供资金、资助半导体产业的发展。中国在毫米波芯片突破的速度以及成就,引起了世界半导体行业的震动,不少国外科学家纷纷表示不可思议。美国一位名为戴维斯的院士于20日在社交平台上调侃道:中国科学家不睡觉吗?能在短时间内连续取得突破,用不了多长时间,中国科学家将会引领世界半导体行业的发展。

    单片机 毫米波 芯片

  • 闲鱼如何一招保证推荐流稳如泰山?

    背景 近几年互联网的快速发展中,互联网业务发展越来越复杂,业务也被拆分得越来越细,阿里内部业务也发生着翻天覆地的变化,从最初的单体应用,到后面的分布式集群,再到最近几年大中台小前台的业务形态,作为后端开发,依赖的服务方越来越多,同时依赖服务方的故障因素也会越来越多的会影响到闲鱼的上层业务的稳定。 例如在闲鱼主推商品流的业务场景中,商品中台数据库的抖动会造成主推商品流的卡顿或者页面显示空窗现象,个性化算法中台向量集群的扩容也会造成推荐内容延时被拖到非常长,后面还有可能依赖其他的业务中台,作为上层业务如何保证依赖的中台越来越多的情况下,还能保证服务的稳定性运行呢? 业界主流溜一遍 根据日常解决问题的经验,不能直接解决业务问题本身,可以折中解决业务问题也是一个不错的办法。上述业务问题中,当业务出现问题的时候,可以折中提前置备好所需的业务数据返回给业务,也是一个不错的办法。在闲鱼主推商品流的业务场景中,对可靠性要求非常高,因为推荐商品失败,用户看到推荐页出现空窗,业务所需的数据量大概是5页的推荐商品数据流,大概为3M左右。在实际解决问题中,笔者从业务所需的数据量级、可靠性要求级别等角度调研了业界一些通用解决办法。 为了给用户良好的业务体验,笔者主要使用服务端数据冗余、客户端数据冗余、熔断机制等方法,来确保用户对闲鱼App流畅的业务体验。笔者主要服务端数据冗余聊聊本地缓存,根据笔者在阿里断网演练的经验,断网演练时,某个区域的所有服务不可用,所以笔者在技术选型的时候没有考虑分布式缓存Redis,Memcache之类等。目前就业界本地缓存库有Guava、Caffeine、Ehcache、Cache2K、ConcurrentHashMap、Varnish、JackRabbit等,笔者选取了几个性能比较优越的缓存库比较,下面笔者从功能上、性能上、易用性、集群能力、可视化报表上等分别比较。 笔者对照目前业务需求对比了上述四个组件,在定时失效策略能力上,除了ConcurrentHashMap都是使用定时失效能力,并且三个组件时间复杂度都是O(n)。在集群能力上,Ehcache依赖自身网络协议 保证集群数据一致性,不能使用现有集团内部组件保证数据一致性。在本地缓存能力上, Caffeine的写能力优于Guava 。在组件通用性上,Guava组件更加通用。最终笔者选用了Guava组件作为本地缓存组件,因为Guava 组件更加通用,并且很方便与 阿里内部中间件集成配合使用。在集群数据同步能力,通过配置中心中间件实现数据同步,在可视化报表能力,通过定时任务打印日志,日志采集系统采集展示数据报表。接下来笔者介绍如何添加上述三种能力和优化Guava本地缓存能力。 我的集群Cache组件 Guava Caching提供了定时失效、最后访问失效、最后写入失效策略等能力,笔者主要使用了定时失效能力,在首次写入Key后,指定时间过后,该Key会失效,业务获取该Key时,会调用reload方法重新同步加载该Key。如果使用invalid方法使该Key无效,业务并发再次获取该Key,多线程加载该Key时,只有一个业务线程调用load方法加载该Key,其他线程等待该Key,加载完成后重新进入指定时间后流程。笔者在原来Guava Cache本地缓存能力上结合Spring自动 注入能力,进行工程化,添加了业务所需的如下三种能力 当key失效,本地缓存reload异步加载 失效本地缓存key,整个集群机器上key失效能力 定时上报本机Cache内各个Key在本地缓存大小 根据上述业务能力,整体流程图如下所示 集群本机Cache组件的整体结构类图如下: AbstractCacheLoader重写父类CacheLoader的reload方法,添加异步加载能力 LocalCacheManager管理所有实现AbstractCacheConfig的子类,并上报各自本地缓存大小。 实现AbstractCacheConfig的业务配置子类,例如CurrentCacheConfig等,调用invalidate方法时,会通知集群本机Cache中Key消息。 业务同学在使用集群本机Cache组件时,只需要继承AbstractCacheConfig抽象类,声明为Bean,即用集群本机Cache组件,业务同学无需关心集群环境问题等。相比Guava cache组件,提供了集群本机Cache Key失效能力,以及对Key集中管理和监控,减少了单独使用Guava cache带来内存无法管理的问题。 接下来笔者介绍使用集群本机Cache组件能力的典型案例:自动置备兜底组件。 典型栗子:自动置备兜底组件 兜底是在服务遇到外部依赖异常(超时、不可用、数据异常等),可能导致服务无可以返回的正常数据时,服务通过使用兜底数据提供服务的一种降级行为。自动置备兜底组件使用集群本机cache的本机缓存能力和集群失效能力,很方便完成兜底数据置备。在闲鱼的业务场景中使用兜底置备组件的场景非常多,例如闲鱼主推商品流等。 兜底自动置备组件原理如下: 使用定时任务scheduleX2定时触发服务集群中的一台服务器,执行兜底置备,更新tair缓存内容,失效本地缓存,即失效集群server的本地缓存。 当业务请求获取key时,会获取tair中最新内容,并缓存到本地,再次请求,直接本地获取。 详细业务请求流程图如下所示 自动兜底组件已经在闲鱼的多个业务场景得到使用,在断网演练情况下,服务端RT延时和成功率有了明显的提升,闲鱼主要业务场景的提升效果如下: 展望 在集群本机cache组件使用过程中也发现一些问题,例如有时候集群本机cache缓存错误的配置,需要重启集群或者等待key失效,所以需要集群本机cache组件web管理功能。在集群本机cache组件推广中,发现有些业务场景的缓存key对应的缓存对象比较大,或者缓存key的数量比较多,后期按照key使用频率等级,考虑对于长期不使用的key存储到本机磁盘上,让业务方不关心缓存Key过大可能造成的问题。

    架构师社区 互联网 架构 算法 数据库 闲鱼

  • 国内外大厂oncall情况大比拼!谷歌员工竟然抢着oncall?

    如今国内互联网行业中,许多公司都会明里暗里要求程序猿们oncall,也就是24小时待命,随叫随到,不分白天黑夜,出了问题就打电话找人解决。 比如这位小哥哥爆料自己曾经的遭遇: 类似这样的事情还有很多,百度员工表示大晚上被叫起来oncall,处理十几分钟就睡不着了,第二天一天都废了,感觉身体都受不了了。 字节跳动员工也怨声载道,不oncall就跟放假一样,再这么下去,自己就跳不动了。还有人想干脆请假一天在家写代码,因为每天都被oncall搞死了,来头条体验最差的就是oncall。 蚂蚁员工说出去旅游一定要带电脑,在景区随时应急,钉钉一响,整个人就像惊弓之鸟。 另一个前蚂蚁员工更惨,去度蜜月全程背着15寸的电脑,登机起飞前还被拉了个钉钉会议,蜜月回来就准备换电脑换工作了。 看来oncall几乎要引起众怒了,许多人都反感这种制度,形容它是“恶臭的风气”,只有管理水平差才会造成这样。 有人好奇,国内大厂都要求程序猿oncall,那么号称相对轻松的国外大厂是怎么操作的呢,oncall情况会不会好一点? 微软员工表示不仅要oncall,而且是白嫖。微软没有运维,所有运维都是攻城狮自己弄,很多组都要7*24oncall值班,不过有时候老板会给调休。 亚马逊员工说oncall到怀疑人生。 facebook员工说不仅要oncall,破事还特别多。 uber员工表示oncall没钱,国外大多数公司都要求oncall不给钱,少数公司比如谷歌会给钱。 谷歌员工出来验证,oncall会有工资,按小时计费。 还有谷歌员工说有的组需要oncall,取决于项目。 一个前谷歌员工说sre(网站可靠性工程师)需要oncall,开发基本不用。 其他谷歌员工说确实有的组专门招sre来oncall,但近几年sre的预算卡得紧,只能让swe(软件工程师)来oncall,不过一般oncall都没什么事,还给双倍工资,所以许多人都抢着oncall…… 小编看了一圈下来,oncall不仅仅是国内大厂的通病,国外大厂也很难避免,这大概是互联网行业不可避免的现象。 无论是国内还是国外,程序员们都对oncall深恶痛绝,但唯有谷歌员工不仅不讨厌,还抢着要oncall,其他大厂是否应该对照反思一下呢? 第一,尽量招专门的攻城狮去oncall,让开发专门做开发,不要像那位字节员工说的一样,不得不考虑请假在家写代码,只为求个清净。 第二,也是非常重要的一点,oncall要给钱!不能只让马儿快跑,不给马儿吃草,长此以往,什么样的良驹也受不住。大家出来工作,出卖劳动力和时间,都是为了挣钱,不仅给钱,还要在休息时间白白用人,谁能乐意呢? 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    架构师社区 互联网 谷歌 程序猿

  • 在一个执行力极差的团队工作是一种怎样的体验?

    一个执行力极差的团队能把一个公司活活的拖死,在这种团队中工作是一种怎么的体验呢?相信很多小伙伴会对这种团队的工作氛围感兴趣。正好冰河在假期与一位经历过这种团队的朋友聊天,聊到了这个话题,今天就给小伙伴们总结下在一个执行力差的团队工作是一种怎样的体验! 一.方向不对,没有目标 执行力差的团队没有一个明确的方向,更没有为这个方向努力的目标,不知道向哪里努力,团队成员懒散,缺乏斗志。 二.团队定位不行 给团队定位存在问题,不能客观评价自己的团队,明明团队整体能力不行,领导者还凭自己的感觉认为团队能够做超出预期的事情,过分压榨员工,导致员工反感,执行力差。 三.缺乏过程管理 结果固然重要,但没有过程的结果往往是不太现实的,结果的好坏往往取决于整个过程是否达标。缺乏过程管理往往无法取得良好的结果。 四.过份的细化计划 管理者对计划做的有点过份,写代码时恨不得把敲每个字母都列进计划,大部分时间都在排计划,真正做事情的时间不到整体时间的三分之一。再一个就是恨不得把一年的计划细分,管它能不能实现呢,先列上再说,唯一的作用就是告诉你,今年要做这些事,至于能不能完成,另说吧!不,最好是逼着你完成,你反感就对了。 五.无能的绩效管理 绩效管理极度不合理,对于研发团队采取所谓的量化考核,考核指标极度不合理,以提交代码的次数和修改Bug的数量来考核研发团队,去他妈的绩效管理吧,别伤研发人员的自尊。 六.无能的产品经理 产品经理无能,可以拖垮整个研发团队。无法正确把控用户和市场需求,人云亦云,缺乏对需求和产品的深度思考,疲于应付,终日处于修改需求和设计的死循环中,过程中不会输出任何有效的产物,最终产品死掉了,研发团队垮掉了。 七.无能的管理者 所谓兵熊熊一个,将熊熊一窝。管理者无能,首先不从自己身上找问题,总是说效率问题,效率你妹啊,你有效率你来,不要瞎BB,能干事才重要! 八.过份偏袒某个人或团队 项目过程中由于某个人或团队对于计划的安排极度不合理,无法按照计划推进工作,严重阻碍了其他团队的工作。结果领导者说是其他团队的效率问题。如果一个公司由这种领导者主宰,这个公司必死! 九.不能客观的对待问题 出了问题不能客观对待,总是凭领导者自己的感觉来判断问题的严重程度。有时候还会凭空放大问题的严重性,最终让团队其他人背锅。去他妈的背锅侠,我不当。 十.过份强调管理 十个人恨不得九个是管理,过份强调管理,甚至在很小的创业团队,也要事无巨细的管理起来,你上个厕所,拉个屎,都要汇报下,生怕你影响了工作! 十一.正常时间下班是不正常的 恨不得你一天24小时都在工位上,加班成为了每天的“必修课”,如果你哪天没有加班太久,领导会打电话问你是不是状态不好,今天的工作有没有做完,会给你洗脑,说什么再这样项目没法交付之类的鬼话! 以上就是冰河总结的在一个执行力极差的团队工作的11点体验,小伙伴们经历过哪些团队?团队的执行力如何?欢迎在文末留言讨论。

    架构师社区 执行力 团队 绩效管理

  • 骑士卡:基于Kafka搭建消息中心,上亿消息推送轻松完成

    全球购骑士卡是国内领先的会员制特权电商平台,汇聚国内外“吃喝玩乐买”超 300 项会员专属优惠特权。全球购骑士卡基于移动互联生活方式,打通线上、线下消费场景,汇集时下热门、高频的商品及服务优惠。会员可享全国超万家大型商超购物8折起、全国加油7折起、热门电商平台专属4折起、大牌美食餐饮 5 折起等,满足用户吃、喝、玩、乐、买各场景的消费需求。截至2020年,全球购骑士卡已累计服务用户超 5000 万名。2020年4月,全球购骑士卡完成 A 轮数千万美元融资;同年 5 月,全球购骑士卡完成数千万美元 A+轮融资。 新的需求 全球购骑士特权业务的飞速发展,当前每天平均发送的短信量达到了约 200 万+,需要 PUSH 的推送量达到了约 1 亿+,通过微信推送量达到了5000 万+。因此,如何构造建设一个高性能、高稳定性、可扩展的消息中心迫在眉睫。 消息中心技术选型主要参考以下因素: 削峰填谷能力 :消息中心需要处理各条业务线的通知和营销任务的信息,而这些信息根据转化的需要,很大可能会集中化地在短期内进行推送,所以需要系统有削峰填谷的能力。 接口通用能力 :消息中心的接入方不希望被绑定在某个接口上,不需要对该接口进行维护可以供多个业务方进行发送处理。 灵活类型划分 :消息中心需要支持灵活的业务分类配置, 因为我们消息中心这里的业务配置非常多,大类就有短信、PUSH、微信推送,短信里又分通知、验证码和营销类别,而 PUSH 又区分 APNS、渠道服务商等第三方通道,以及 Android 厂商通道。 稳定处理能力 :所依赖的技术产品运行稳定,因为处于消息中心的通道位置,不能忍受产品本身的稳定性波动带来的业务损失。 集群扩展能力 :所依赖的技术产品没有扩容瓶颈,对于我们的业务继续发展有扩展的足够空间,可以快速进行业务扩容诉求。 新的解法 使用消息中间件来做消息中心的通道是显现而见的目标选项,综合对比多种消息的产品,由于骑士卡并没有需要顺序消息、事务消息等高阶功能,而是重点关注以下这些功能点: 队列的扩展能力 :在这方面,RabbitMQ 的单 Queue 的处理能力不容易扩展;而 RocketMQ 的 Topic 是有 ConsumerQueue 的参数来进行配置扩容的,在 Broker 的配置文件里指定,但是对 Broker 层面生效的;而 Kafka 的 Partition 可以每个 Topic 拥有不同的取值。这样在分类灵活性方面,Kafka 是最优的选择,RocketMQ 次之。 通用的接入方式 :本质上 RabbitMQ、RocketMQ、Kafka 都是私有协议的方式接入,比较云上商业版本的接入方式,对于 Kafka 支持最纯粹友好,可以使用官方的接入方式进行接入。 消息的吞吐能力 :在各类消息的对比测试中, 因为 Kafka 本身的处理机制原因,都是由客户端进行拉消息,整个 Broker 的处理方式比别的消息中间件要简洁,而 Kafka 的读写能力/吞吐量都是最大的。 集群稳定性能力 :云上的消息产品都很友好地保持业务的连续性来进行升配操作,并且对于商业版本的 Kafka 做了 Broker 上的优化,存储上的优化,运维上的优化后,不需要担心自建集群出现的不稳定问题,完全满足骑士卡的需求。 业务价值 使用 Kafka 构建消息中心,对骑士卡来说最重要的是 保障了业务的稳健 。利用 Kafka 的吞吐能力,自定义的 partition 设定(扩展),通过弹性扩展消费者实例的方式,自消息中心上线以来,一直运行平稳,没有出现过影响业务的故障。 同时, 系统运维起来十分简单 。利用云上的Kafka能力,避免了测试期自建集群莫名其妙的 Broker 故障,不需要投入额外的资源来保障消息中间件正常工作。并且可以通过白屏化的升级操作来匹配骑士卡的业务发展,也可以按需要来快速调整实例数。 值得一提的是,使用云产品 Kafka,无论在生产环境还是本地开发测试环境,都可以直接使用云产品,最大限度减少通用产品依赖,让团队专注于业务的开拓实现, 极大的提升了团队工作效率。 目前,消息中心作为业务运营推广的基石,发挥着重要作用,对于新业务的接入,通过消息队列的配置修改即可完成,对现有业务可以做到无侵入,尽可能的减少了故障发生的可能。

    架构师社区 Kafka 骑士卡 消息中心

  • 日订单量达到100万单后,我们做了订单中心重构

    ,sql在互联网行业,很多系统的访问量很高,即便在凌晨两三点也有一定的访问量。由于数据迁移导致服务暂停,是很难被业务方接受的!下面就聊一下在用户无感知的前提下,我们的不停机数据迁移方案! 在服务层对订单表进行增删改的地方,要同时操作新库(分库分表后的数据库表)和老库,需要修改相应的代码(同时写新库和老库)。准备校验程序脚本,用于校验新库和老库的数据是否一致。 注意:对于更新操作,如果新库没有相关记录,需要先从老库查出记录,将更新后的记录写入新库; 利用脚本程序,将某一时间戳之前的老数据迁移到新库。注意:1,时间戳一定要选择开启双写后的时间点,比如开启双写后10分钟的时间点,避免部分老数据被漏掉;2,迁移过程遇到记录冲突直接忽略,因为第2步的更新操作,已经把记录拉到了新库;3,迁移过程一定要记录日志,尤其是错误日志,如果有双写失败的情况,我们可以通过日志恢复数据,以此来保证新老库的数据一致。 第3步完成后,我们还需要通过脚本程序检验数据,看新库数据是否准确以及有没有漏掉的数据 数据校验没问题后,开启双读,起初给新库放少部分流量,新库和老库同时读取。由于延时问题,新库和老库可能会有少量数据记录不一致的情况,所以新库读不到时需要再读一遍老库。然后再逐步将读流量切到新库,相当于灰度上线的过程。遇到问题可以及时把流量切回老库 读流量全部切到新库后,关闭老库写入(可以在代码里加上热配置开关),只写新库 迁移完成,后续可以去掉双写双读相关无用代码。 利用数据同步工具 准备迁移程序脚本,用于做老数据迁移。 利用脚本程序,将某一时间戳之前的老数据迁移到新库。注意:1,时间戳一定要选择开始运行Canal程序后的时间点(比如运行Canal代码后10分钟的时间点),避免部分老数据被漏掉;3,迁移过程一定要记录日志,尤其是错误日志,如果有些记录写入失败,我们可以通过日志恢复数据,以此来保证新老库的数据一致。 数据校验没问题后,开启双读,起初给新库放少部分流量,新库和老库同时读取。由于延时问题,新库和老库可能会有少量数据记录不一致的情况,所以新库读不到时需要再读一遍老库。逐步将读流量切到新库,相当于灰度上线的过程。遇到问题可以及时把流量切回老库 关闭Canal程序 通过前面的描述,不难看出我们的分库分表方案有一些缺陷,比如采用hash取模的方式会产生数据分布不均匀的情况,扩容缩容也非常麻烦。 这些问题可以用一致性hash方案解决。基于虚拟节点设计原理的一致性hash可以让数据分布更均匀。 而且一致性hash采用环形设计思路,在增减节点时,使得数据迁移的成本会更低,只需要迁移临近节点的数据。不过需要扩容时基本上要成倍扩容,在hash环上每个节点间隙都增加新的节点,这样才能分摊所有原有节点的访问和存储压力。 由于篇幅原因,这里不详细介绍一致性hash了,网上有很多相关资料,大家有兴趣可以仔细研究一下。 降级方案 大促时某些时间点瞬间生成订单量很高。我们采取异步批量写数据库的方式,来减少数据库访问频次,进而降低数据库的写入压力。详细步骤: 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    架构师社区 数据库 重构 订单中心

  • 曾因出演《西游记》爆红,现在转行写代码身价过亿!不一样的CTO!

    8 6版《西游记》给大家留下了许多耳熟能详的经典角色,其中红孩儿的形象更是家喻户晓。 当年电视剧一播出,这个虎头虎脑、人小鬼大的萌娃就俘获了众多观众的心。 多年后,红孩儿又借助一句“你是猴子请来的救兵吗”再次走红网络,可谓是国产剧中的经典儿童形象之一。 许多童星长大后都选择继续演艺事业,比如杨幂、曹骏、释小龙等,想必许多人会感到好奇,有着如此高的起点,红孩儿的扮演者如今是否还在演艺圈,有没有成为家喻户晓的大明星?这么多年过去了,如今的他是什么模样? 红孩儿的扮演者叫赵欣培,1977年出生的他如今已经44岁了,他并没有沿着小时候的路继续当一名演员,而是成了一家农业互联网公司的CTO,现在的他长这样,你还能从他身上看到红孩儿的影子吗? 当年《西游记》播出之后,赵欣培饰演的红孩儿红遍大江南北,许多导演都向他伸出了橄榄枝,但他却志不在此,拒绝了许多不错的角色,选择淡出演艺圈,继续自己的学业。 九十年代正是计算机刚刚兴起的时候,赵欣培对此颇感兴趣,一门心思扑到了计算机的研究中。初中时他就成立了一个电脑兴趣组,和一些同样喜爱电脑的同学讨论电脑知识。1995年,赵欣培考上了北京大学的计算机系,1999年毕业后,他又进入中国科学院软件研究所攻读硕士和博士。 在2004年《艺术人生》的特别节目《西游记再聚首》中,当时还是中国科学院在读博士的赵欣培曾出现在节目上,还和扮演“牛魔王”的演员王夫棠上演了一出“父子相认”的感人戏份。 毕业后,赵欣培一直从事相关行业,2014年,他和几个朋友创立了北京农管家科技有限公司,赵欣培担任公司CTO,如今身价已经上亿。 如今的赵欣培发福不少,虽然被许多网友戏称为“长残了”,但他早已远离演艺圈,并不需要保持颜值和身材。现在的他从事着自己感兴趣的工作,谈起农业互联网时,他会兴奋地展望未来,流露出创业者特有的的快乐和自豪。 也许有人会惋惜赵欣培没有继续在演艺圈打拼,放弃了一个那么高的起点,但是谁又能说他如今不是成功的人生呢? 现在的赵欣培拥有世俗意义上的成功:事业有成,身家上亿,家庭温暖,让人们看到了童星转行后另一种成功的打开方式。这条路并非我们一笔带过的那么一帆风顺,创业路上曾遇到很多困难和坎坷,身边的人也曾多次劝他放弃,但他不愿意轻易放弃自己的梦想,而是想各种办法解决困难,让公司最终走上了正轨。 因此,成功的第一要义就是坚持,如果遇到困难就轻易放弃,大概没有哪个人能成功了,因为世上没有一帆风顺的成功之路。梦想只是指路明灯,若没有勇气和毅力为自己披荆斩棘,很难保持明灯长亮直至最后。 但我想探讨另外一种可能:即使赵欣培没有选择创业,不是创业公司CTO,而是一直在自己热爱的行业里深耕技术,做一名普普通通的程序员,他的人生也并非不成功。成功的定义有很多,有人觉得像明星那样在聚光灯下名利双收是成功,而默默无闻泯然众人则是失败,果真是这样吗? 赵欣培的性格、兴趣都不适合演艺圈,如果当初他顺应潮流留在演艺圈,现在的他颜值并非一流,也许很难出头,而且违背本心的他大概率会过着比较痛苦的生活。 许多像赵欣培一样的童星,年纪轻轻就进入演艺圈,得到了年少成名的机会,也许他们并不是真心喜欢表演,但从小生活在聚光灯下,时间久了就容易迷失本心,长大后他们依然选择在演艺圈逐梦。可惜的是,真正幸运的童星并不多,大多数童星都在奋斗十几年后黯然离去。 在《明朝那些事》书中写了无数帝王将相的故事,他们手握大权,举足轻重,一举一动都决定着无数人的生命。写了这么多大人物后,作者“当年明月”却以一个远离政坛的人的一生作为全书结尾,那个人就是对功名利禄毫无兴趣,只痴迷名山大川的徐霞客。他一生无心科举,徜徉山水之间,留下的笔记被后人整理为《徐霞客游记》,里面记载了祖国山川的具体情况,涉及到地理、水利、地貌等信息,被誉为十七世纪最伟大的地理学著作,后来被翻译成几十国语言,流传世界。 在当时的时代,徐霞客的一生绝对谈不上成功,世人眼中唯有考科举、走仕途才是正道。但作者说,所谓千秋霸业都是粪土,无论怎样的权势富贵最终都会归于尘土,那么究竟什么才是成功呢? 答案揭晓:成功只有一个,就是按照自己的方式度过一生。 在人生道路的选择上,每个人都会面临几个关键的节点,有人很幸运,自己喜欢的事情和世俗意义上的成功重合,大多数人则没有那么幸运,选择了那个看似正确实则违背本心的选项。 最初决定放弃演艺事业时,赵欣培根本不知道自己的未来会是怎样,他只是凭借直觉和兴趣做出了自己的选择,而遵从内心的选择恰恰让他充满干劲,最终获得了成功。 所以,成功的第二要义是选择自己喜欢的方式,毕竟生命短暂而珍贵,如果短短几十年都违背本意做着令自己痛苦的事情,这样的人生又有什么意义呢?

    架构师社区 代码 西游记 赵欣培 红孩儿

  • 如何避免让微服务测试成为研发团队最大的瓶颈?

    本文主要为大家介绍微服务测试:基于服务契约信息,降低云上微服务测试成本。该系列文章基于阿里云商业化产品 EDAS 的微服务实践,如果您的团队具备较强的微服务测试能力,那么希望我们在微服务测试方面的实践和背后的思考,可以为您提供一些参考。 前言 随着云原生时代的到来,越来越多的应用生在云上,长在云上,且随着越来越多的企业开始上云,云原生也是企业落地微服务的最佳伴侣。但云上应用易测性受到了很大的挑战,如何提高云上应用易测性,增强 DevOps 能力,是微服务测试要解决的核心问题。 在详细讲述微服务测试之前,先给大家讲一个场景。 上图是一个典型的企业微服务应用架构图,为了考虑安全性,云上应用通常部署在云上虚拟局域网内,统一通过网关对外暴露服务。对于负责 Product Service 应用的同学来说,我只想测试一下该应用对应的服务是否可用,他会怎么做呢? 方案一 进入该应用部署所在的机器(ECS)或者容器(Pod),通过 curl 命令验证该服务是否可用 方案二 将该应用暴露给公网访问,通过本地命令行工具或者 Postman 工具验证该服务是否可用 方案三 拉一条网络专线,打通云上专有网络VPC与办公网网络,通过本地命令行工具或者 Postman 工具验证该服务是否可用 从以上场景,我们可以总结出云上微服务测试几点问题: 云上网络拓扑复杂 暴露公网访问,会出现黑客攻击,引发安全风险 拉一条网络专线,浪费资源成本 明明只想要一个简单的测试能力,成本却如此之高。上述场景还仅仅是一个简单的调试功能,如果是压测、自动化回归、巡检等其他测试及稳定性保障手段,不仅仅要解决上述场景遇到的问题,还需要自建工具,脑补一下,都觉得成本太高。因此,我们需要微服务测试来帮助我们解决这些问题,进一步加速软件交付效率。 为什么我们需要微服务测试 产品能力 提供测试、压测、自动化回归、巡检等能力,形成一个微服务测试解决方案 试想一下,研发同学提交代码并部署,可以使用测试工具,验证服务逻辑正确性;可以使用压测工具,验证服务性能指标;验证通过后,开始进行冒烟测试,可以使用自动化回归工具,编写冒烟用例;冒烟通过后,开始进行历史功能回归,可以使用自动化回归工具,编写回归用例;回归通过后,提交测试验收,测试只需要验证新功能,新功能验证通过后,即可提交发布。 发布后,进行线上环境验证,需要回归历史功能主流程,可以使用自动化回归工具,编写主流程回归用例,新功能手工验证;主流程回归通过且新功能验证通过,代表发布完成;研发同学可以使用巡检工具,配置线上巡检;一旦巡检告警,即可先于用户发现问题,并解决问题。 我们是将阿里巴巴沉淀的测试解决方案产品化输出,帮助云上业务实现高质量地实现快速交付。 易用且安全 开箱即用,无需关注专有网络VPC下的网络拓扑;安全可靠,拥有在办公网下的测试体验。 试想一下,企业为了安全隔离,研发环境、测试环境、预发环境、生产环境部署在不同的专有网络 VPC 内,如果用户自建测试工具,需要解决测试工具到不同环境的网络互通问题,企业 IT 人员明明只想要一个简单的测试工具,却因为上云之后,要解决复杂的云上网络拓扑,远远没有结束,为了能够在办公网使用该测试工具,还需要保证该测试工具能够被办公网访问,此时又面临着网络安全的考验。我们希望有一个能够开箱即用且安全可靠的方案,能够让上云的企业 IT 人员拥有在办公网测试体验的测试工具。 低成本 弹性拉起测试机/施压机,用完销毁,能够大幅度降低构建测试工具需要的机器资源及人力成本。 试想一下,企业上云是为了降低成本,应用托管极大地降低了资源成本和运维成本,但测试成本并没有降低。企业 IT 人员自建测试工具需要准备测试机/施压机,该部分机器长期占用且存在闲置,资源成本开销大,尤其是在性能压测场景,资源成本开销会更大。除了资源成本外,企业 IT 人员还需要研发测试工具,人力成本及时间成本非常高,基本上每个企业都需要一套测试工具。我们希望有一个低成本的方案,不仅提高企业的资源利用率,同时降低企业 IT 人员开发和维护测试工具的成本。 微服务生态 云上已提供了大量的微服务产品,解决了微服务应用的托管、治理、诊断,微服务测试补齐微服务能力。 试想一下,如何测试一个微服务接口,需要了解接口入参和出参,如果是研发同学-服务提供者,可能比较熟悉该接口,如果是测试同学,甚至是其他研发同学,可能就需要文档,甚至是口口相传,微服务治理已经可视化应用的服务契约信息,结合服务契约信息,只需按照测试需要,选择应用->框架->服务->方法,配置测试参数,即可进行测试,降低了服务契约同步的成本。 结合上述 4 点,测试同学只需负责用例编写+测试验收,接口调试、接口性能水位、用例自动化均可赋能给研发同学,就像早期 DevOps 一样,降低研发运维之间的反馈回路,提高软件交付效率,DevTest,降低研发测试之间的反馈回路,在保证交付质量的前提下,进一步提升软件交付效率,同时主动创建巡检任务,定时监控线上服务可用率,先于用户发现问题,解决问题。 EDAS3.0 微服务测试实践 前提条件:微服务应用已接入 EDAS3.0。 下面我们来体验一下,EDAS 上如何使用微服务测试的能力。 服务测试 登录 EDAS 控制台,在页面左上角选择地域; 左侧导航栏选择:微服务治理 -> Spring Cloud -> 服务测试 -> 查询服务; 单击某个服务的详情 -> 展示元数据列表; 单击某个方法的测试 -> 进入测试页面(已帮助用户填充参数模板); 点击执行即可。 服务压测 登录 EDAS 控制台,在页面左上角选择地域; 左侧导航栏选择:微服务治理 -> Spring Cloud  -> 服务压测 -> 创建场景; 选择需要压测的应用 -> 选择框架 -> 选择服务 -> 选择方法; 填写压测参数,点击确认; 进入压测场景列表页,点击详情; 进入压测详情页,点击启动,等待施压机准备就绪; 点击详情,进入压测性能数据报告页,实时查看性能数据; 自动化回归 登录 EDAS 控制台,在页面左上角选择地域; 左侧导航栏选择:微服务治理 -> Spring Cloud -> 自动化回归 -> 创建用例; 添加步骤: 选择应用 -> 选择框架 -> 选择服务 -> 选择方法; 填写参数; 断言/出参提取; 可以添加多个步骤; 保存用例; 点击执行; 通过执行历史,查看用例是否通过; 服务巡检 登录 EDAS 控制台,在页面左上角选择地域; 左侧导航栏选择:微服务治理 -> Spring Cloud -> 服务巡检 -> 创建巡检任务; 选择需要巡检的应用 -> 选择框架 -> 选择服务 -> 选择方法; 填写巡检参数及断言内容,点击确认; 进入巡检任务列表页,点击启动,即开始巡检; 巡检失败时,可以通过失败记录进行查看,也可以添加告警,通过钉钉、短信、邮件的方式告警; 微服务测试实现细节 工具能力 将阿里巴巴集团内实践的测试工具产品化输出,压测、自动化回归、巡检,降低用户研发工具的成本。 网络互通 利用阿里云现有网络打通技术方案(ENI 挂载),打通云产品专有网络 VPC 与用户专有网络VPC 应用安装微服务 Agent 时,主动将该应用所在的网络信息(专有网络 VPC,虚拟交换机 VSwitch,安全组 SecurityGroup)上报至服务端,根据应用所在的网络信息,即可打通云产品专有网络 VPC 与用户专有网络 VPC,实现云产品服务直接访问用户专有网络 VPC 部署的服务。 弹性资源 云产品使用自己的资源账号购买弹性机器,安装测试工具 服务契约 微服务治理已经可视化服务契约信息,微服务测试直接查询服务契约信息即可 不止是微服务测试 本文介绍了微服务测试的几个能力,补齐了微服务生态测试的能力,即将推出智能流量测试:提供微服务架构下的流量生产录制生产回放、生产录制线下回放、测试用例自动化生成、回归测试场景自动化覆盖等能力,助力您的应用以更低的成本轻松完成测试验证,欢迎前来体验。 除了 EDAS(企业级分布式应用服务),微服务测试能力已被 MSE(微服务引擎)集成,还将被 AHAS、CSB、SAE 等云产品集成。将微服务测试能力作为一个基础能力被更多云产品集成,另外,将跟更多微服务产品 ARMS (应用实时监控服务)、ACM(应用配置管理)等形成联动,助力保障云上业务稳定性,让业务永远在线。 免责声明:本文内容由21ic获得授权后发布,版权归原作者所有,本平台仅提供信息存储服务。文章仅代表作者个人观点,不代表本平台立场,如有问题,请联系我们,谢谢!

    架构师社区 微服务 微服务测试 EDAS

发布文章