Browsed by
标签:架构

一个APP引发的故事-2021

一个APP引发的故事-2021

閱讀本文約花費: 18 (分鐘)郑爽和张恒纠纷的前因后果 昨天郑爽和张恒的事情出来之后,好多朋友都发来私信,本来最近我正在忙着赶台湾娱乐史康熙风云系列最后一章,不得不停下来延更一次,各位谅解。 昨天我看市面上很多文章都在关心代孕方面的问题,但我发现几乎没有人提到这两人的矛盾和纠纷到底是怎么来的,那么今天在这里就给大家讲讲整个故事。 开门见山的先说结论,郑爽张恒当初闹矛盾分手,根本的原因是因为钱。 故事要从2014年讲起…… 2014年年中,有个叫茹晨的人创办了一家名为创客星球的公司,这个茹晨早年是电视财经口出身,曾在央视财经频道《对话》节目做过导演,后来在第一财经做《头脑风暴》和《波士堂》之类的商业类节目。 茹晨下海成立了创客星球之后,拿到了一笔数百万的天使投资,最开始是做一档《创客星球》同名商业节目,每期节目都有创业者上台讲述自己的商业计划和产品概念,现场的投资人们决定要不要投钱什么的,公司打出的概念是电视+众筹。 这种类型的节目毕竟小众,没什么影响,于是到了2016年,创客星球重新提出要做中国第一个机器人格斗大赛,讲述的资本故事变成了电视+科技+线下产业,又融到了一轮千万级的融资,有了钱之后公司就开始正式筹备机器人格斗比赛了,张恒也就是在此时登场的。 (公司融资之后请来了李连杰站台)—— 张恒是个90后,家里面是做家居生意的,从小就被父母送到国外,此前在俄亥俄州立大学念书,属于…

Read More Read More

恒大造车的荒诞故事

恒大造车的荒诞故事

閱讀本文約花費: 33 (分鐘)2020 年农历新年前不久,广州东南 60 多公里外的恒大汽车南沙基地,工作人员已为重要人物的到来准备多日。 这个临近珠江出海口的基地占地 126 万平米,相当于特斯拉上海工厂的 1.5 倍。开工一年多,H 型排列的三间巨大厂房尚未完工,只有最右侧的总装车间封顶,园区里大部分还是泥地。 要客要参观的总装车间设备尚不齐全,也没完成调试。整个基地只有三四十个工人,根本没法站满车间里的数百工位。 更大的问题是到视察前夜,恒大汽车的研发团队都不知道这个基地未来究竟生产什么车型。 但视察当日,从南沙港快速路驶下的要客车队没有经过一片狼藉。从进入园区开始,到视察目的地总装车间,车队都行驶在混凝土路面上。基地工程师和施工人员提前冲洗路面、扫清积水、在两侧摆上鲜花。来不及处理的烂泥地和建筑垃圾,则被一人多高的盆栽挡住。 打开车门,许家印伴随地方领导一行走入车间,看到的基本是工业 4.0 概念宣传片的画面:德国西门子的传送带将白色车壳往前运输,特斯拉工厂同款的橙色库卡机械臂灵活地转动,对车身射出黄色的电焊弧。更远一些,身着白色工服的工人站在完工的汽车边上,拧着扳手。 有限的人手都被安排在参观路线周边的工位。平时不在产线工作的基地工程师那天也穿着工服,站在工位里。如果参观者走远一些,就会看到厂房更多区域空空荡荡,没有工人。 但现场的…

Read More Read More

2020 中国技术力量年度榜单正式揭晓,见证创新技术的力量

2020 中国技术力量年度榜单正式揭晓,见证创新技术的力量

閱讀本文約花費: 8 (分鐘)| 编辑:沈于蓝 | 设计:朱亿钦 | 责编:王皓月 **** 开源社引言 赵生宇 (Frank) 作为开源领域的新生一代力量,给整个开源界带来了创新与活力。不仅在疫情期间发起了 Wuhan2020 开源项目,还将多个社区的力量进行了连接,在开源和公益的结合上给全社会做出了一个精彩的典范。同时也积极倡导开源教育,将自己在开源领域的经验分享给大家,带动了一批学员加入到开源的浪潮中来。还有 2019 以及 2020 年的开源年报,也是在 Frank 的带动下推动的,今天的开源年报 GitHub 数据分析部分还被他做成了一个开源协作项目,真的是非常符合开源的行事作风。 目前,作为一名博士生的 Frank 将开源作为一个跨学科背景下的研究课题,同样是令人期待,开源在技术之上还包括了心理学、管理学、社会学、法学等不同学科的内容,融合了跨学科内涵的开源领域太需要深入而长期的基础研究了,祝愿赵博士后面不断取得开源研究的成果,为全人类这场伟大的协作奠定更多的基石。 ——王伟,开源社执行长、华东师范大学数据科学与工程学院研究员 300+参评项目,100+入围项目,10000+开发者公开票选,20+专家评审,10+主编团打分,历经数月打磨,11 月 19 日,由 InfoQ 发起并组织的【 2020 中国技术力量年度榜单评选】结果正式揭晓。 2020 年度十大开源新锐项目…

Read More Read More

从基础设施到云原生应用,全方位解读阿里云原生新锐开源项目

从基础设施到云原生应用,全方位解读阿里云原生新锐开源项目

閱讀本文約花費: 11 (分鐘)简介: 2020年11月19日,由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开,阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model(OAM)荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”,阿里云原生拿了一个分量十足的“大满贯”。 2020年11月19日,由 InfoQ 主办的“2020中国技术力量年度榜单盛典”隆重召开,并正式揭晓了“开源杰出贡献人物”、“开源新锐项目”和“云原生行业落地典范”三大重量级奖项。在此前的入围赛中,仅“开源新锐项目”单项,阿里云原生就入围了10多个开源项目,在创新能力、社区成就和用户反馈等多项指标中一骑绝尘,占据了参评项目整体近五分之一。而在本次揭晓的“2020中国技术力量年度榜单”决赛结果中,最终阿里云技术专家罗毅荣获“十大开源杰出贡献人物”、Open Application Model(OAM)荣登“十大开源新锐项目”、由阿里云原生团队支撑的完美日记电商业务案例获评“2020年度十大云原生行业落地典范”,阿里云原生拿了一个分量十足的“大满贯”。 在 2020 年,阿里不仅实现了双十一核心系统全面云原生化,一举成为全球规模最大、实力最硬核的云原生实践,并首次实现自研、开源、商业“三位一体…

Read More Read More

2020 中国技术力量年度榜单揭晓,华为云持续引领云原生产业

2020 中国技术力量年度榜单揭晓,华为云持续引领云原生产业

閱讀本文約花費: 3 (分鐘)今日,由InfoQ 发起并组织的【2020 中国技术力量年度榜单评选】结果正式揭晓,华为云表现抢眼,一连拿下四个席位:KubeEdge入选年度十大开源新锐项目,华为云云原生边缘技术方案、华为云云原生高性能计算技术方案入选年度十大云原生创新技术方案,北京网路智联科技有限公司基于华为云原生的创新实践则被评为年度十大云原生行业落地典范。 在年度十大开源新锐项目的评选竞争尤为激烈,吸引了最近三年内,开源领域活跃度最高、最具创新性和发展潜质的近150+项目参与报名,由华为云开源的首个云原生边缘计算项目KubeEdge成功入选。 KubeEdge于2019年就由华为云捐献给CNCF,旨在加速云原生向边缘计算产业的渗透和融合,推动了云原生产业的成熟。此外,基于丰富的实践积累,华为云还向CNCF捐献了首个云原生批量计算项目Volcano。 在时下最炙手可热的“云原生”领域,华为云云原生边缘技术方案、华为云云原生高性能计算技术方案入围年度十大云原生创新技术方案。由华为云支持的北京网路智联科技有限公司上报的全国高速公路取消省界收费站项目也获得认可,成功入选十大云原生行业落地典范。 北京网路智联科技有限公司基于华为云原生边缘技术方案打造了全国高速公路取消省界项目,管理了全国29个省、市、自治区的将近10万边缘节点,超过30万边缘应用的部署,支撑了高速公路收费业务的不断调整、…

Read More Read More

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

Kubernetes 社区是如何运作的系列之二——康威定律和SIG

閱讀本文約花費: 10 (分鐘)生产关系能否决定生产力?为什么这个社会需要管理?Kubernetes 是如此的成功,它的开源治理和技术架构是有着非常密切的关系的。 Tue Feb 6, 2018 | 3000 Words | 大约需要阅读 6 分钟 | | 康威定律(Conway’s Law) 随着信息技术的发展,以及现实的IT公司的成功,如Amazon、Netflix,以及云计算的普及,微服务的实践正在走向很多传统用户,然而,实施微服务的过程中,和DevOps的理念一样,人们发现并非仅仅是技术所能够解决的。还要涉及到组织架构。于是,伴随着微服务的发展,一位很少被人提及的科学家被推到了前端,也是被人忽视而尘封的科学家。 时间要拨回到1967年,Melvin Conway 以独特的视角观察到一个组织的组织结构会对其开发的系统有很大的影响。并撰写了“How Do Committees Invent” 这样一篇影响深远的论文,其中被人们广为知道的结论: 设计系统【这里也不仅仅是指信息系统】的组织,其产生的设计和架构等价于组织间的沟通结构。 该定律基于这样一个推理:为了能够让软件之间的模块相互作用,软件的撰写者们必须相互频繁的进行沟通,因此,系统的软件界面结构将会反映出打造此系统的组织的社会边界,要知道跨边界的沟通是比较困难的。Conway 定律的目的是试图说明这是蛮常见的社会学…

Read More Read More

Kubernetes 社区是如何运作的系列之一——哲学及治理

Kubernetes 社区是如何运作的系列之一——哲学及治理

閱讀本文約花費: 6 (分鐘)开源社区治理,正在逐渐的成熟,Linux、CNCF、OpenStack、Apache基金会等俨然成为软件业的中流砥柱,本土是不是应该潜心学习这些先进的管理/治理方式?精英制还是完全民主化?是不是应该以实际行动和理性思考来作出正确的判断? Mon Feb 5, 2018 | 1900 Words | 大约需要阅读 4 分钟 | | 引子 在2017年,关于容器的管理和调度平台,战火的硝烟渐渐的平息,Kubernetes 以压倒性的优势占据了这个细分领域的霸主,如下图来自 thenewstack 的调查: 如果仅仅从纯技术的角度而言,Kubernetes 和其它平台是半斤八两,处于伯仲之间,那么在社区的运营和赢得人们信任的方面,Kubernetes绝对是No.1,没有哪家能够相提并论。即使是Docker本身拥有无数拥泵的情况下,是容器的默认事实标准,也无法抵挡透明、开放、协作的Kubernetes社区的魅力。开源之道在Kubernetes 之所以成功的背后神秘力量 进行过专门的表述。 在上个月的中旬,Software Engineering Daily 的Jeff 撰写了一篇非常棒的文章:Kubernetes 的“下沉”,意指Kubernetes已经像Linux在单机操作系统的地位一样,成为分布式系统平台的默认选择。成为了分布式系统事实…

Read More Read More

用户画像的创建与应用

用户画像的创建与应用

閱讀本文約花費: 8 (分鐘)用户画像(User Profile),作为大数据的根基,它完美地抽象出一个用户的信息全貌。 用户画像(User Profile),作为大数据的根基,它完美地抽象出一个用户的信息全貌,为进一步精准、快速地分析用户行为习惯、消费习惯等重要信息提供了足够的数据基础,奠定了大数据时代的基石。 什么是用户画像? 用户画像又称用户角色,作为一种勾画目标用户、联系用户诉求与设计方向的有效工具。它是通过大量的定性和定量研究而创建的,用户画像在各领域得到了广泛的应用。 用户画像(Persona)回答了“我们为谁设计”这个问题,它是基于研究成果的一个强大的工具,通过优化用户体验研究来帮助产品功能的创造,它不仅代表一个特定的用户,并且它们可以被理解为所有潜在用户的行为,态度,技能和背景的典型特征。 为什么我们要使用用户画像? 许多关于产品设计的研究数据是很难处理的,特别是当我们需要在整个过程中注意数据的时候。因此,用户画像将是一个相对更为现实和具体的对象,虽然不是一个真实的人,但它是许多真实人物角色的最典型的形象。它可以提醒我们用户的需求,并帮助我们创造一个更好的用户体验模型,因为真实用户在使用产品时会感觉更舒适。 UX用户画像 UX用户画像是指在使用习惯,产品要求,偏好和目标上具有相似点的产品或服务的用户的代表或领袖。他们可以描述潜在用户的需求,并帮助开发者在功能设计期间…

Read More Read More

Service Mesh实践之Istio初体验

Service Mesh实践之Istio初体验

閱讀本文約花費: 16 (分鐘)微服务国内发展背景: 2014年,Martin Fowler撰写的《Microservices》使得许多国内的先行者接触到微服务这个概念并将其引入国内,2015年越来越多的人通过各种渠道了解到微服务的概念并有人开始在生产环境中落地,2016-2017年,微服务的概念被越来越多的人认可,带动了一大批公司以微服务和容器为核心开始技术架构的全面革新。 至今微服务已经历了两代发展,第一代以Spring Cloud为代表的微服务开发框架,该框架在微服务发展的前几年一度独领风骚,甚至在部分人群中成为微服务的代名词,但事实上该微服务框架并不是唯一实现微服务的方式;第二代微服务技术为服务网格(Service Mesh),它的出现解决了大部分开发人员在使用Spring Cloud中遇到的不足和痛点。 Service Mesh是如何解决这些问题的,又是何以赢得众多开发者的支持呢?笔者就这些问题给大家分享一篇以Istio为代表的第二代微服务实践。 一、微服务和Istio Service Mesh基本概念 服务网格是一个基础设施层,主要用于处理服务间的通信。云原生应用有着复杂的服务拓扑,服务网格负责在这些拓扑中实现请求的可靠传递。在实践中,服务网格通常实现为一组轻量级网络代理,它们与应用程序部署在一起,而对应用程序透明。 图1展示了服务网格的拓扑,当微服务数量增多达到几十上…

Read More Read More

使用Istio治理微服务入门

使用Istio治理微服务入门

閱讀本文約花費: 20 (分鐘)近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务。再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄,服务治理难搞! 一、微服务的“痛点” 微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰、职责单一的服务接口,这样每一块规划为一个微服务。微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如:gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包,对服务治理的内容涉及甚少。 微服务治理是头疼的事,也是微服务架构中的痛点。治理这个词有多元含义,很难下达一个精确定义,这里可以像小学二年级学生那样列出治理的诸多近义词:管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言,治理体现在以下诸多方面: 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说,微服务其实是一个“大系统”,要想将这个大系统全部落地,绝非易事,尤其是之前尚没有一种特别优雅的技术方案。多数方案(…

Read More Read More

商旅网站用户画像的解决方案

商旅网站用户画像的解决方案

閱讀本文約花費: 11 (分鐘)(一)用户画像的目的与意义、构建步骤 用户画像(persona)的概念最早由交互设计之父Alan Cooper 提出:是指真实用户的虚拟代表,是建立在一系列属性数据之上的目标用户模型。随着互联网的发展,现在我们说的用户画像是根据用户人口学特征、网络浏览内容、网络社交活动和消费行为等信息而抽象出的一个标签化的用户模型。通过各个维度对用户或者产品特征属性的刻画,并对这些特征分析统计挖掘潜在价值信息!完美地抽象出一个用户的信息全貌,可以看作企业应用大数据的根基。构建用户画像的核心工作,主要是利用存储在服务器上的海量日志和数据库里的大量数据进行分析和挖掘,给用户贴“标签”,而“标签”是能表示用户某一维度特征的标识。 为了能解决业务问题,用数据来帮助企业了解用户和定位产品,更好地解决业务问题,首先必须明确业务目标。用户画像是帮助企业明确目标客群,当企业了解了自己的用户都长什么样子以后,接下来的任务就是如何将有类似画像特征人群的潜在用户变成自己的用户,也就是在营销上获新客的过程。 所以,从大的框架来看,用户画像承载了两个业务目标: 一是如何准确的了解现有用户; 二是如何在茫茫人海中通过广告营销获取类似画像特征的新用户。 那么用户画像具体有什么作用,能帮助我们达到哪些目标呢?大体上可以总结为以下几个方面: 1. 精准营销:精准直邮、短信、App消息推送、个性化广告…

Read More Read More

图文:千万级高性能长连接网关是如何搭建的?

图文:千万级高性能长连接网关是如何搭建的?

閱讀本文約花費: 17 (分鐘)实时的响应总是让人兴奋的,就如你在微信里看到对方正在输入,如你在王者峡谷里一呼百应,如你们在直播弹幕里不约而同的 666,它们的背后都离不开长连接技术的加持。 每个互联网公司里几乎都有一套长连接系统 ,它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模,业务场景变得更复杂后,更有可能是多个业务都需要同时使用长连接系统。 业务间分开设计长连接会导致研发和维护成本陡增、浪费基础设施、增加客户端耗电、无法复用已有经验等等问题。共享长连接系统又需要协调好不同系统间的认证、鉴权、数据隔离、协议拓展、消息送达保证 等等需求,迭代过程中协议需要向前兼容,同时因为不同业务的长连接汇聚到一个系统导致容量管理的难度也会增大。 经过了一年多的开发和演进,经过我们服务面向内和外的数个 App、接入十几个需求和形态各异的长连接业务、数百万设备同时在线、突发大规模消息发送等等场景的锤炼,我们提炼出一个长连接系统网关的通用解决方案,解决了多业务共用长连接时遇到的种种问题。 知乎长连接网关致力于业务数据解耦、消息高效分发、解决容量问题,同时提供一定程度的消息可靠性保证。 我们怎么设计通讯协议? 业务解耦 支撑多业务的长连接网关实际上是同时对接多客户端和多业务后端的,是多对多的关系,他们之间只使用一条长连接通讯。 这种多对多的系统…

Read More Read More

kubernetes实践:Istio之策略与遥测

kubernetes实践:Istio之策略与遥测

閱讀本文約花費: 9 (分鐘)一:Istio简介 1.Istio定义 一个用来连接,管理和保护服务的开发平台。Istio提供一种简单的方式建立已部署服务网络,具备负载均衡,服务间认证和监控等功能。 而不需要改变任何服务代码。想要为服务增加对Istio的支持,只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理,拦截微服务之间的所有网络通信。 2.为什么需要Istio 随着微服务出现,微服务的连接,管理和监控成为难题。Kubernetes可以处理多个容器的工作负载,但当涉及更复杂的需求时,需要像Istio这样的服务网格。 3.Istio的主要功能 a.流量管理(Pilot): 控制服务之间的流量和API调用的流向,使得调用更灵活可靠,并使网络在恶劣情况下更加健壮。 b.可观察性: 通过集成zipkin等服务,快速了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。 c.策略执行(mixer): 将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。 d.服务身份和安全(Istio-auth): 为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。 4.Envoy架构 a.svcA服务作为客户端点用服务端svcB,svc…

Read More Read More

Serverless 与容器决战在即?有了弹性伸缩就不一样了

Serverless 与容器决战在即?有了弹性伸缩就不一样了

閱讀本文約花費: 16 (分鐘)导读:Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容。有人说 Serverless 是容器 2.0,终有一天容器会和 Serverless 进行一场决战,分出胜负。实际上,容器和 Serverless 是可以共存并且互补的,特别是在 Autoscaling 相关的场景下,Serverless 可以与容器完美兼容,弥补容器场景在使用简单、速度、成本的缺欠。 当我们在谈论”弹性伸缩”的时候 当我们在谈论”弹性伸缩”的时候,我们在谈论什么?”弹性伸缩”对于团队中不同的角色有不同的意义,而这正是弹性伸缩的魅力所在。 从一张资源曲线图讲起 这张图是阐述弹性伸缩问题时经常引用的一张图,表示的是集群的实际资源容量和应用所需容量之间的关系。 其中红色的曲线表示的是应用实际所需的容量,因为应用的资源申请量相比节点而言会小很多,因此曲线相对比较平滑; 而绿色的折线表示的是集群的实际资源容量,折线的拐点表明此时进行了手动的容量调整,例如增加节点或者移除节点,因为单个节点的资源容量固定且相对较大,因此以折线为主。 首先,我们先看左侧第一块黄色栅格的区域,这个区域表示集群的容量无法满足业务的容量所需,在实际的场景中,通常会伴随出现由于资源不足而无法调度的 Pod 等现…

Read More Read More

微服务架构下的分布式限流方案全解析

微服务架构下的分布式限流方案全解析

閱讀本文約花費: 9 (分鐘)1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源、数据库的写操作、频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流。 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS,但如果实际情况遇到高于3000的QPS该如何解决呢? 所以限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率就可以拒绝服务、等待、降级。 学习如何去实现一个分布式限流框架,首先,我们需要去了解最基本的两种限流算法。 2.限流算法 2.1漏桶算法 漏桶算法思路很简单,水(也就是请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。示意图(来源网络)如下: 2.2令牌桶算法 令牌桶算法和漏桶算法效果一样但方向相反的算法,更加容易理解。随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入令牌(…

Read More Read More

Java 应用性能调优实践

Java 应用性能调优实践

閱讀本文約花費: 24 (分鐘)Java 应用性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢、接口超时,服务器负载高、并发数低,数据库频繁死锁等。尤其是在”糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和代码的臃肿,各种性能问题开始纷至沓来。Java 应用性能的瓶颈点非常多,比如磁盘、内存、网络 I/O 等系统因素,Java 应用代码,JVM GC,数据库,缓存等。笔者根据个人经验,将 Java 性能优化分为 4 个层级:应用层、数据库层、框架层、JVM 层,如图 1 所示。 图 1.Java 性能优化分层模型 每层优化难度逐级增加,涉及的知识和解决的问题也会不同。比如应用层需要理解代码逻辑,通过 Java 线程栈定位有问题代码行等;数据库层面需要分析 SQL、定位死锁等;框架层需要懂源代码,理解框架机制;JVM 层需要对 GC 的类型和工作机制有深入了解,对各种 JVM 参数作用了然于胸。 围绕 Java 性能优化,有两种最基本的分析方法:现场分析法和事后分析法。现场分析法通过保留现场,再采用诊断工具分析定位。现场分析对线上影响较大,部分场景(特别是涉及到用户关键的在线业务时)不太合适。事后分析法需要尽可能多收集现场数据,然后立即恢复服务,同时针对收集的现场数据进行事后分析和复现。下面我们从性能诊断工具出发,分享搜狗商业平台在其中的一些案例与实践。 性…

Read More Read More

Scroll Up