- 博客(6875)
- 资源 (9)
- 收藏
- 关注
RSS订阅原创 性能优化十大策略：如何系统地有层次地优化性能问题？
各种性能问题的解决，需要采用一些策略；而且不同的人和不同的场景中，会采用有时相同有时迥异的策略，恰如韩愈所说的“草树知春不久归，百般红紫斗芳菲”。但花草树木争奇斗艳，说到底是因为“知春不久归”。同样的道理，这些性能优化策略，有时候很容易想到，有时候并不是那么直观。所以，我们需要系统地有层次地思考，而这一讲就是帮助你建立这样的思路。通过总结十大策略，希望你可以多从不同角度，思考同一个问题；有时候一个问题看似无解，但多方位思考，可能会突然发现非常好的解决方案。
2025-04-25 10:45:10
377
原创 性能优化六大原则：三要三不要，快速有效地进行优化
在实际的性能优化中，我们需要考虑的因素很多，也经常需要在多个角度和目标间做一些平衡和取舍。为了帮助你把握这些，我个人总结出了六条原则，我把它们概括为：“三要，三不要三个“要”原则是：要优先查最大的性能瓶颈，性能分析要确诊性能问题的根因，性能优化要考虑各种的情况。三个“不要”的原则是：不要做过度的、反常态的优化，不要过早做不成熟的优化，不要做表面的肤浅优化。接下来，我们一个个地讲一下这六个优化原则。唐朝的名相魏征说过：“求木之长者，必固其根本”。意思是说，如果要一棵树长得高，必须让它的根牢固。
2025-04-25 10:41:18
289
原创 网络篇：如何步步拆解处理复杂的网络性能问题？
不管计算机技术如何发展，网络永远是极其重要的一部分；而且随着互联网业务的多样化和复杂化，对网络性能的要求只会越来越高。不管应用如何变化，高性能网络必不可少，而且会变得更复杂。这让我想起了宋朝大词人张先的《千秋岁》里面的几句词，“天不老，情难绝。心似双丝网，中有千千结。网络是整个互联网服务的一部分，各种因素之间互相影响。和网络性能演化密切相关的因素包括：上层服务需求的越来越多样化，计算机硬件和操作系统的持续进化，各层网络协议的不断优化，以及底层介质的演化（比如5G）。
2025-04-25 10:39:14
134
原创 如何根据性能优缺点选择最合适的存储系统？
存储系统，顾名思义，是用来存放我们各种程序和服务的数据。随着现代互联网服务的大数据化，几乎所有的业务都离不开存储系统的支持。各种存储系统的基础是传统硬盘或者固态硬盘，这两种硬盘在成本、性能、大小方面各有千秋。我想起了宋代有首诗叫《雪梅》，里面比较了白雪和梅花的优缺点：“梅须逊雪三分白，雪却输梅一段香。这句诗用来形容传统硬盘和固态硬盘的关系还挺合适的。在实际使用中，我们要注意它们的性能优缺点，从而适当来作取舍。比如，如果系统对IOPS或者延迟要求很高，恐怕只有SSD才能满足要求。
2025-04-25 10:35:01
396
原创 内存篇：如何减少延迟提升内存分配效率？
我们都知道宋代词人辛弃疾，他曾经这样憧憬他的战场梦想：“马作的卢飞快，弓如霹雳弦惊。” 我们开发的应用程序对内存的分配请求延迟，也有相似的期盼，就是要动作飞快。如果内存分配延迟太大，整个程序的性能自然也高不上去。如何实现这个梦想呢？就需要我们的代码和程序，尽量降低对内存的使用大小和内存带宽，尽量少地请求分配和释放内存，帮助系统内存状态不至于太过碎片化，并且对代码结构做一些相应地优化。
2025-04-25 10:28:41
285
原创 - CPU篇：如何让CPU的运行不受阻碍？
这一讲我们讨论了计算机的运算核心，CPU的结构，尤其是它内部的和性能相关的部件，并澄清了一些术语。CPU是服务器性能的最重要的部分；因为不管程序代码如何优化，最后都要转换成指令，让CPU来执行。不管其他部件如何和CPU交互，最终目的是让CPU尽快地拿到指令，并满载执行。唐代有个诗人叫李贺，他曾经形容跨马奔驰的愿景：“大漠沙如雪，燕山月似钩。何当金络脑，快走踏清秋。我们常把CPU类比大脑，CPU性能优化的目标，就是让它的运行不受阻碍，如千里马一样任意驰骋。
2025-04-25 10:24:04
141
原创 性能分析概述：性能问题归根结底是什么原因？
我们的儒家思想提倡“格物致知”，就是说要深入探究事物的原理，而从中获得知识和智慧。性能优化能否成功，也需要探究一个系统中性能的真正问题，找到性能的最大瓶颈。格物致知时，还需要“正心“和”诚意”，就是要实事求是和端正态度，从而科学而系统地收获知识。我们做性能分析时候，也是需要根据实际的数据和Profiling等测试结果，找到性能的瓶颈，并合理地解决性能问题。
2025-04-25 10:20:21
278
原创 九条性能测试的经验和教训：如何保证测试结果可靠且可重复？
当年毛主席给彭德怀写过几句诗：山高路远坑深，大军纵横驰奔。谁敢横刀立马？唯我彭大将军。打仗有很多坑，做性能工作也有很多坑。我们要把性能测试的工作做好，本身就不容易。山高路远都不在乎，但一定要注意其中的陷阱。所以只有不断地学习别人总结的经验，吸取别人的教训，解决测试的各种挑战，才能得出可靠，可重复并且有意义的性能测试结果。
2025-04-25 09:59:50
221
原创 性能测试的工具：七大测试场景如何选择高质量的测试工具？
古人说：“工欲善其事，必先利其器”。业界已经有很多好用的工具，一般都能满足大多数场合的测试要求，会让我们的测试工作如虎添翼。虽然有些环境下我们经常倾向于自己开发某些工具，但是往往会花费很多时间，而且很容易陷入各种各样的坑中，因此尽量避免自己开发。这一讲介绍的几款工具适用于不同的场合，如果你能合理运用它们，应该会取得事半功倍的效果。
2025-04-25 09:55:28
299
原创 性能测试的规划和步骤：为什么性能测试不容易一蹴而就呢？
郑板桥在他的七言绝句《竹石》中说：“咬定青山不放松，立根原在破岩中“，赞扬竹子目标明确，基础扎实，而且百折不挠。我们做性能测试也是如此。只有条理分明，目标清楚，目的明确，规划仔细，执行得力，才能“千磨万击还坚劲，任尔东西南北风“。这样的测试或许需要执行很多次，因为经常需要调整测试的方法，但不达目的，我们决不罢休。
2025-04-24 10:35:25
208
原创 性能测试的种类：如何快准狠地抓住一个测试的本质？
这一讲重点讲了几种性能测试。在工作中和别人交流时，你一定还会听到各种不同叫法的性能测试。我从业多年的总体感觉就是，性能测试的种类太多，甚至对某一种测试怎么进行也众口纷纭。给人的感觉，就像古诗里面所说的，“乱花渐欲迷人眼”。虽然各种性能测试叫法不一，但万变不离其宗，你只要主要抓住几点就行，比如分类的方式，流量的大小和测试的目的。希望通过本讲的讨论，你能对不同的性能测试之间的区别更清楚一些了，以后工作交流和阅读文献时能搞清楚它们是什么种类的测试，从而对症下药，做好测试规划和合理的分析。
2025-04-24 10:33:04
351
原创 经验总结：必须熟记的一组常用性能数字
今天讲了几十个平时经常用到的性能数字，希望起到抛砖引玉的效果。你可以在此基础上，在广度和深度上继续扩展记忆。宋代诗人苏轼曾经作诗夸奖朋友：“前身子美只君是，信手拈来俱天成”，这里的“子美”是唐朝大诗人杜甫的字。这两句是夸朋友写文章写得好，能自由纯熟的选用词语或应用典故，用不着怎么思考，不必费心寻找，如同杜甫转世。我们如果对各种性能数据足够熟悉，如掌上观纹，自然也就能达到那种对性能问题的分析信手拈来的境界。
2025-04-24 10:31:00
538
原创 性能数据的展示：一图胜千言，说出你的数据故事
我们都学过宋朝的词人柳永的词，他有两句词是这么写的：“便纵有千种风情，更与何人说？这里他其实是在感叹自己虽有满腹经纶和深厚情感，但无人可以诉说。我们虽然不是词人，但在做过性能测试或者根因分析后，可能经常会有很多新奇的发现，希望向同事和领导讲解。但是性能问题往往牵涉很广，描述起来并不容易，别人可能很难理解。这时候我们的感觉就是“我有千种风情”，可是如何说啊？希望通过这一讲，能让你对在图文并茂地来“诉说”这方面能有些提升。
2025-04-24 10:28:42
219
原创 性能数据的分析：如何从大量数据中看出想要的信号？
性能工程和优化离不开对大量性能数据的研究和分析，那么如何“拨开云雾见天日”，看出里面的端倪和问题呢？我们这一讲就讨论了几种情况，包括对一个和多个时间序列的分析；也讨论进行数据分析的时候需要注意的地方。古人讲“格物致知”；对我们来讲，性能数据就是我们要“格”的物。只有合理而系统地分析这些数据，才能收获“守得云开见月明”的恍然大悟之感。
2025-04-24 10:25:01
464
原创 概率统计和排队论：做性能工作必须懂的数理基础.
要想精通任何一门学问和工作，牢固的基础是必须的。对IT工作，包括设计系统、编写程序、系统维护和性能优化而言，牢固的数学基础会使我们的工作如虎添翼。这正如古人赞赏梅花时所说得：“不经一番寒彻骨，怎得梅花扑鼻香“。我们也常说“根深才能叶茂”，今天讲的内容，包括概率统计和分布模型的知识，都是这样的基础和根基，希望你能牢牢掌握。
2025-04-24 10:22:23
503
原创 性能工程三定律：IT业和性能优化工作的“法律法规”
我们今天讨论的性能工程相关的三大法则，分别是帕累托法则、阿姆达尔定律和利特尔法则。可以说，这些法则就是IT业和性能优化工作的“法律法规”，有了它们，我们在实际工作中才能做到“有法可依，有法必依”。熟悉并熟练应用这几个法则，对我们的工作是会有很大的帮助的。孟子说：“不以规矩，不能成方圆。”熟悉并熟练应用这几个“规律法则”，对我们的工作是会有很大的帮助的。
2025-04-24 10:20:03
324
原创 导读：专栏是怎么设计的？需要哪些知识？
最后两讲是介绍性能和容量工程师这个职业，包括这一工作的特点和职业前景。随着大数据和互联网的飞速发展，我坚信这方面的工作越来越重要。尤其是大公司，都会专门招聘这方面的人才组成特殊的性能优化和容量管理团队。所以，针对有志于从事这一行业的朋友，我会分享这方面的面试经验。得益于这种工作的特点，性能优化和容量效率需要了解的知识和技能比较广泛。人们常说：“读书破万卷，下笔如有神。”读书写文章是这个道理，做性能优化工作也是如此。只有不断学习计算机各方面的相关知识，博览群书，才能在解决性能问题时得心应手。
2025-04-24 10:18:43
214
原创 程序员也要关心整个系统和公司成本吗？
对代码和程序的性能优化，以及对系统容量的效率提升，和我们共同关心爱护的东西息息相关。从代码模块，到整个系统，到互联网服务，到公司运营，再到我们的社会，都依赖于我们每个人的责任和贡献。你和我或许是一介普通工程师和程序员，但人们常说“位卑未敢忘忧国”。我们虽然没必要拔高到忧国忧民的高度，但是也要认真做好我们的份内份外的事情。
2025-04-24 10:16:23
577
原创 程序员为什么要关心代码性能？
说起代码性能，首先我们需要弄清楚什么样的代码算是性能好？怎么样算是性能不好？代码性能表现在很多方面和指标，比较常见的几个指标有吞吐量（Throughput）、服务延迟（Service latency）、扩展性（Scalability）和资源使用效率（Resource Utilization）。吞吐量：单位时间处理请求的数量。服务延迟：客户请求的处理时间。扩展性：系统在高压的情况下能不能正常处理请求。资源使用效率：单位请求处理所需要的资源量（比如CPU，内存等）。
2025-04-24 10:14:37
564
原创 微博Service Mesh实践之路（下）
今天我从Motan-go Agent和统一服务治理中心的具体实现这两个方面，给你讲解了Weibo Mesh的技术细节，你可以看到很多都是微博基于自身业务特点定制化的解决方案。对于大部分中小团队来说，除非从一开始就采用了云原生应用的部署方式，否则Istio等开源方案并不能直接拿来就用，都需要从自身的业务特征和既有技术体系出发，选择一条适合自己的Service Mesh实践之路。
2025-04-23 16:38:45
693
原创 微博Service Mesh实践之路（上）
今天我给你讲解了微博是如何一步步走向Service Mesh之路的，从这个过程你可以看出微博的Weibo Mesh并不是一开始就是设计成这样的，它是随着业务的发展，对跨语言服务调用的需求日趋强烈，才开始探索如何使得原有仅支持Java语言的服务化框架Motan支持多语言，在这个过程中又不断尝试了各种解决方案之后，才笃定了走Agent代理这条路，并实际应用到线上。
2025-04-23 16:37:29
545
原创 Istio：Service Mesh的代表产品
专栏上一期我们聊了Service Mesh，并以Linkerd为例介绍了Service Mesh的架构。随着技术发展，现在来看Linkerd可以说是第一代Service Mesh产品，到了今天当我们再谈到Service Mesh时，往往第一个想到的是。为什么我认为Istio可以称得上是Service Mesh的代表产品呢？现在我们一起走进Istio的架构，看看它各部分的实现原理，希望能让你有所收获。
2025-04-23 16:35:36
634
原创 下一代微服务架构Service Mesh
Service Mesh的概念最早是由Buoyant公司的CEO William Morgan在一篇文章里提出，他给出的服务网格的定义是：专栏里我就不解释教条的定义了，感兴趣的话你可以点击链接阅读原文，这里我来谈谈我对Service Mesh的理解。我认为是Service Mesh是一种新型的用于处理服务与服务之间通信的技术，尤其适用以云原生应用形式部署的服务，能够保证服务与服务之间调用的可靠性。
2025-04-23 16:32:33
771
原创 微服务混合云部署实践
今天我给你讲解了微服务混合云部署必须解决的三个问题：跨云服务的负载均衡、跨云服务的数据同步、跨云服务的容器运维，以及微博在微服务混合云部署时的实践方案，可以说正是由于采用了混合云部署，才解决了微博在面对频繁爆发的热点事件带来突发流量时，内部资源冗余度不足的问题。虽然云原生应用现在越来越流行，但对于大部分企业来说，完全脱离内部私有云并不现实，因为云也不是完全可靠的，一旦云厂商出现问题，如果没有内部私有云部署的话，那么服务将完全不可用。如果你的服务对高可用性要求很高，那么混合云的方案更加适合你。
2025-04-23 16:29:15
676
原创 微服务多机房部署实践？
今天我给你讲解了微服务多机房部署时要面临的三个问题，一是多机房访问时如何保证负载均衡，二是多机房之间的数据如何保证同步，三是多机房之间的数据如何保证一致性，并给出了微博在多机房部署微服务时所采取的解决方案，对于大部分中小业务团队应该都有借鉴意义。可以说多机房部署是非常有必要的，尤其是对可用性要求很高的业务来说，通过多机房部署能够实现异地多活，尤其可以避免因为施工把光缆挖断导致整个服务不可用的情况发生，也是业务上云实现混合云部署的前提。
2025-04-23 14:15:47
819
原创 如何做好微服务容量规划？
今天我从两个方面具体给你讲解了微服务如何做好容量规划的问题，即做好容量评估和调度决策。容量评估方面，首先要通过压测获取集群的最大容量，并实时采集服务调用的数据以获取集群的实时运行负荷，这样就可以获取集群的实时水位线。而调度决策方面，主要是通过水位线与致命线和安全线对比来决定什么时候该扩缩容。而扩缩容的数量也是有讲究的，扩容的机器数一般按照集群机器数量的比例来，而缩容一般采取逐步缩容的方式以免缩容太快导致反复扩容。
2025-04-22 15:44:13
522
原创 微服务如何实现DevOps？
在介绍DevOps之前，我先来带你回顾一下传统的业务上线流程：开发人员开发完业务代码后，把自测通过的代码打包交给测试人员，然后测试人员把代码部署在测试环境中进行测试，如果测试不通过，就反馈bug给开发人员进行修复；如果通过，开发就把测试通过的代码交给运维人员打包，然后运维人员再发布到线上环境中去。可见在传统的开发模式下，开发人员、测试人员和运维人员的职责划分十分明确，他们往往分属于不同的职能部门，一次业务上线流程需要三者之间进行多次沟通，整个周期基本上是以天为单位。
2025-04-22 15:43:01
544
原创 微服务容器化运维：微博容器运维平台DCP
今天我给你讲解了微博容器运维平台DCP的架构，主要包括基础设施层、主机层、调度层以及编排层，并详细介绍了每一层的功能实现，以及各自承担的不同职能。下面这张图是一次完整扩容流程，包括了资源评估、配额评估、初始化、容器调度、部署服务、服务依赖、服务发现以及自动扩缩容等，DCP正是通过把这些过程串联起来，实现容器运维的。
2025-04-22 15:41:22
836
原创 微服务容器化运维：容器调度和服务编排
今天我给你讲解了容器运维平台的另外两个关键组成：容器调度和服务编排，并给出了常用的解决方案。你的业务团队在选择解决方案时，要根据自己的需要选择合适的方案，而不是理论上最好的。比如Kubernetes解决方案在容器调度、服务编排方面都有成熟的组件，并且经过大业务量的实际验证。但是要考虑到Kubernetes本身的复杂性以及概念理解的门槛，对于大部分中小业务团队来说，在生产环境上使用Kubernetes都会显得大材小用，并且还需要部署并运维Kubernetes周边的一些基础设施，比如etcd等。
2025-04-22 15:38:48
731
原创 微服务容器化运维：镜像仓库和资源调度？
今天我给你讲解了容器运维平台的两个关键组成，镜像仓库和资源调度。镜像仓库帮我们解决的是Docker镜像如何存储和访问的问题，在业务规模较大时，各个业务团队都需要搭建自己的私有镜像仓库。类似Harbor这种开源解决方案能很好地解决权限控制、镜像同步等基本问题，关于高可用性的要求以及上云支持等业务场景，你可以参考我给出的解决方案，它是经过微博实际线上业务验证过的。
2025-04-22 15:35:06
658
原创 微服务为什么要容器化？
Docker是容器技术的一种，事实上已经成为业界公认的容器标准，要理解Docker的工作原理首先得知道什么是容器。容器翻译自英文的Container一词，而Container又可以翻译成集装箱。我们都知道，集装箱的作用就是，在港口把货物用集装箱封装起来，然后经过货轮从海上运输到另一个港口，再在港口卸载后通过大货车运送到目的地。这样的话，货物在世界的任何地方流转时，都是在集装箱里封装好的，不需要根据是在货轮上还是大货车上而对货物进行重新装配。
2025-04-22 10:41:57
615
原创 DevOps 什么意思
DevOps 是一种现代软件开发和运维的方法论，旨在通过文化、工具和实践的结合，帮助组织更快、更可靠地交付价值。它不仅适用于技术团队，还对企业的整体业务敏捷性和竞争力有重要影响。
2025-04-22 10:40:59
352
原创 微服务架构该如何落地？
今天我给你讲解了微服务架构如何在业务中进行落地，总结来讲就是，首先你必须组建一支合适的技术团队，这其中不仅要包含资深的架构师，还需要包含业务的开发者。在选择业务进行微服务架构改造时，不能追大求全，正确的做法应当是先以一个适当规模的业务进行微服务改造，走完整个微服务架构落地的过程，从而找出问题，不断打磨到成熟可用的状态，再推广到更多更重要的业务当中。在改造的过程中，要做好技术取舍，以团队人员的实际情况以及业务的实际需求为准绳，切忌追新立异，避免给业务引入不可控因素，留下“架构债”。
2025-04-22 10:40:05
671
原创 微服务架构该如何落地？
今天我给你讲解了微服务架构如何在业务中进行落地，总结来讲就是，首先你必须组建一支合适的技术团队，这其中不仅要包含资深的架构师，还需要包含业务的开发者。在选择业务进行微服务架构改造时，不能追大求全，正确的做法应当是先以一个适当规模的业务进行微服务改造，走完整个微服务架构落地的过程，从而找出问题，不断打磨到成熟可用的状态，再推广到更多更重要的业务当中。在改造的过程中，要做好技术取舍，以团队人员的实际情况以及业务的实际需求为准绳，切忌追新立异，避免给业务引入不可控因素，留下“架构债”。
2025-04-22 10:37:06
775
原创 如何搭建微服务治理平台？
可以说一个微服务框架是否成熟，除了要看它是否具备服务治理能力，还要看是否有强大的微服务治理平台。因为微服务治理平台能够将多个系统整合在一起，无论是对开发还是运维来说，都能起到事半功倍的作用，这也是当前大部分开源微服务框架所欠缺的部分，所以对于大部分团队来说，都需要自己搭建微服务治理平台。不过好在微服务治理平台本身的架构并不复杂，你可以根据自己的实际需要，来决定微服务治理平台具备哪些功能。
2025-04-22 10:35:22
625
原创 如何管理服务配置？
今天我给你讲解了微服务架构下如何使用配置中心对服务的配置进行管理，以及实际业务中可能用到的场景，最后给出了一些开源配置中心的解决方案。关于业务中是否需要用到配置中心，以及选择哪种配置中心，要根据实际情况而定，如果业务比较简单，配置比较少并且不经常变更的话，采用本地配置是最简单的方案，这样的话不需要额外引入配置中心组件；
2025-04-22 10:32:50
978
原创 服务调用失败时有哪些处理手段？
今天我给你讲解了微服务架构下服务调用失败的几种常见手段：超时、重试、双发以及熔断，实际使用时，具体选择哪种手段要根据具体业务情况来决定。根据我的经验，大部分的服务调用都需要设置超时时间以及重试次数，当然对于非幂等的也就是同一个服务调用重复多次返回结果不一样的来说，不可以重试，比如大部分上行请求都是非幂等的。至于双发，它是在重试基础上进行一定程度的优化，减少了超时等待的时间，对于长尾请求的场景十分有效。采用双发策略后，服务调用的P999能大幅减少，经过我的实践证明是提高服务调用成功率非常有效的手段。
2025-04-22 10:13:21
558
原创 服务端出现故障时该如何应对？
今天我们探讨了微服务系统可能出现的三种故障：集群故障、单IDC故障、单机故障，并且针对这三种故障我给出了分别的解决方案，包括降级、限流、流量切换以及自动重启。在遇到实际的故障时，往往多个手段是并用的，比如在出现单IDC故障，首先要快速切换流量到正常的IDC，但此时可能正常IDC并不足以支撑两个IDC的流量，所以这个时候首先要降级部分功能，保证正常的IDC顺利支撑切换过来的流量。而且要尽量让故障处理自动化，这样可以大大减少故障影响的时间。
2025-04-21 17:00:50
771
原创 如何使用服务路由？
今天我给你讲解了服务路由的作用，简单来讲就是为了实现某些调用的特殊需求，比如分组调用、灰度发布、流量切换、读写分离等。在业务规模比较小的时候，可能所有的服务节点都部署在一起，也就不需要服务路由。但随着业务规模的扩大、服务节点增多，尤其是涉及多数据中心部署的情况，把服务节点按照数据中心进行分组，或者按照业务的核心程度进行分组，对提高服务的可用性是十分有用的。
2025-04-21 16:59:39
904
原创 如何使用负载均衡算法？
今天我给你讲解了最常用的五种客户端负载均衡算法的原理以及适用场景，在业务实践的过程汇总，究竟采用哪种，需要根据实际情况来决定，并不是算法越复杂越好。比如在一种简单的业务场景下，有10个服务节点，并且配置基本相同，位于同一个数据中心，此时客户端选择随机算法或者轮询算法既简单又高效，并没有必要选择加权轮询算法或者最少活跃连接算法。
2025-04-21 16:57:58
364
Linux系统技术可以学习一下
2024-01-26
播为主播提供一站式直播必备工具 包含弹幕助手、屏幕美化、语音播报、弹幕点歌等主播必备核心功能,目前已支持虎牙、斗鱼,抖音等、平台
2023-10-13
TestSyncMethods.java
2021-07-25
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人