刚刚，阿里巴巴集团CEO、阿里云智能集团董事长兼CEO吴泳铭在2024云栖大会上发表主题演讲——“

阿里妹导读本文是技术人面试系列JVM篇，面试中关于JVM都需要了解哪些基础？一文带你详细了解，欢迎收藏！JVM内存划分1、JVM运行时数据区域堆、方法区（元空间）、虚拟机栈、本地方法栈、程序计数器。Heap(堆)：对象的实例以及数组的内存都是要在堆上进行分配的，堆是线程共享的一块区域，用来存放对象实例，也是垃圾回收（GC）的主要区域；开启逃逸分析后，某些未逃逸的对象可以通过标量替换的方式在栈中分配。堆细分：新生代、老年代，对于新生代又分为：Eden区和Surviver1和Surviver2区。方法区：对于JVM的方法区也可以称之为永久区，它储存的是已经被java虚拟机加载的类信息、常量、静态变量；Jdk1.8以后取消了方法区这个概念，称之为元空间（MetaSpace）；当应用中的

阿里妹导读好的单元测试不仅可以验证代码结构设计的是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。导读随着我们各种“code大赛”的不断推进，大家对于单元测试也越发重视。好的单元测试不仅可以验证代码结构设计得是否合理，而且可以提前发现代码中的漏洞，将线上风险扼杀在摇篮中。写好单元测试是每一位程序员的基本功，但是有不少同学对于单元测试有些知其然但不知其所以然，对于单元测试的底层逻辑并未深入研究过，只停留在使用的层面。本文从常用的单元测试框架出发，对Mockito框架深入浅出的讲解，希望能帮到每一位同学。单元测试框架Java中存在很多单元测试框架，每种框架有着自己独特的特点，根据不同的需求和团队要求，每位同学所使用的框架不尽相同，目前主流的测试框架有且不仅有以下几种：JUnitJUnit是Java中最常用的单元测试框架。该框架提供了丰富的测试与断言方法，例如：assertNull、assertTrue、assertEquals等，使用方法比较简单。JUnit目前已经更新到JUnit5版本，该版本提供了更多的新特性，例如：动态测试，依赖注入等，使得该框架更为健壮。官网介绍：https://junit.org/junit5/TestNGTestNG是Java中的另一种测试框架，集团内使用的较为小众。该框架的设计是受了JUnit的启发，初衷是为了更好地支持从单元测试到集成测试的各个方面，用来完成一些JUnit所不能完成的测试任务。该框架较JUnit相比，功能更加强大，提供了更多的高级特性，例如：测试套件、数据驱动测试、依赖测试、并行测试等。在更复杂的测试场景（如参数化测试、依赖测试等）中，TestNG的表现更加优异。官网介绍：https://testng.org/SpockSpock是基于Groovy语言编写的测试框架，该框架可以用来测试Java和Groovy的代码程序。Spock用来写测试代码的语言十分优美、表达力强，这一优点大大提高了测试代码的可读性和可维护性。Spock框架融合了JUnit、jMock、RSpec、Groovy、Scala和Vulcans等多种框架和语言的优点，旨在提供一套强大的测试平台。官网介绍：https://spockframework.org/MockitoMockito不是一个完整的单元测试框架，而是专注于mock对象的创建、验证。它通常与JUnit或TestNG结合使用来简化对复杂依赖的测试。是目前集团内最主流的测试框架，下文中将对该框架进行详细阐述。官网介绍：http://site.mockito.org/EasyMockEasyMock是一套通过简单方法对于给定的接口生成mock对象的类库，通过使用Java代理机制动态生成模拟对象。该框架提供对接口的模拟，能够通过录制、回放、检查三步来完成大体的测试过程，可以验证方法的调用种类、次数、顺序等，还可以令mock对象返回指定的值或抛出指定异常。开发者通过EasyMock可以方便的构造mock对象而忽略对象背后真正的业务逻辑。一般情况下，EasyMock与JUnit或TestNG配合使用。官网介绍：https://easymock.org/PowerMockPowerMock是一种用于Java单元测试的框架，它扩展了其他mocking框架的能力，比如EasyMock和Mockito。PowerMock的主要特点是它可以mock静态方法、私有方法、final方法、构造函数，甚至系统类（如System、String等），这些通常是传统mocking框架所做不到的。有了这些功能，PowerMock在一些复杂场景下进行单元测试更加方便。虽然PowerMock提供了强大的功能，但由于它修改了类加载器和字节码操作，可能会导致一些测试方法与JVM或第三方库之间的兼容性问题。所以，在使用PowerMock时需要权衡其提供的功能和可能带来的复杂性。ps：由于PowerMock的执行速度问题（每个测试类都需要重启spring的TestContext），我们团队内部不建议使用该框架。官网介绍：https://github.com/powermock/powermockJMockJMock是一种用于Java单元测试的框架，属于一种轻量级框架，该框架采用了行为驱动开发（BDD）的测试风格。用来在单元测试中mock接口或类的依赖项，对代码进行隔离测试，而无需关心整个系统的其他部分。JMock支持通过声明式的方式来指定对象间的交互行为。官网介绍：http://jmock.org/大部分开发者在使用这些测试框架时，不会独立使用其中一种，而是会结合使用，例如，可以在JUnit或TestNG的基础上使用Mockito来创建和使用mock对象，来完成比较复杂的测试任务。每个框架都有其独特的优点与缺点，选择哪个框架通常取决于个人偏好、项目需求以及现有代码库的兼容性。当然，实际开发中的单元测试框架远不止以上所提到的这些，还有一些同样优秀的框架在本文中没有介绍，例如：Selenium、Cucumber、Appium等，感兴趣的读者可以自行学习。我们在用什么？目前集团内主流的单元测试框架用的是Mockito框架，该框架的单元测试流程为：以下面的代码为例，展示一下单元测试的常用写法：

阿里妹导读本文讨论了在不使用websocket做服务端推送的情况下，如何写出一个健壮的前端轮询。文章提供了一些常见的前端轮询的应用场景以及可能遇到的问题，欢迎大家一起讨论。一、前言本文的前端轮询主要讨论的是定时异步任务，定时异步任务相比与定时同步任务需要考虑更多的因素。这里的异步任务一般包括发送网络请求及响应后的状态更新。从技术层面上，需要考虑到开启定时、发送请求、状态更新之间的逻辑顺序。此外，本文不讨论利用websocket做服务端推送，只考虑在仅前端变更的情况下做轮询（在某些时候，确实只能如此）。二、应用场景1.获取实时数据，例如数据大屏、实时股价。2.监测进度，例如数据上传进度、下载进度。3.监测后端处理状态，例如提交一批数据后，后端需要对数据进行分析，耗时不确定，前端需要获取分析结果，则此时需要前端轮询。4.检测静态资源是否加载完成（一般来讲是定时同步任务），例如当函数a逻辑需要在静态资源A加载完成后才能执行，则需要在执行函数a之前，开启轮询来判断资源A是否加载完成。三、实现方式3.1.

阿里妹导读对于还没有完整读过源码的小伙伴，本文建议的源码阅读方式，不妨尝试下。从你准备开始阅读源码，你会发现，要做的事情太多了，不过一步一个脚印，你会发现，付出是值得的。灵魂小游戏作为程序员，阅读源码是必备的技能包之一，只会调用api的程序员，不是一个好的程序员。阅读源码不仅可以让我们对所使用的框架、二方包得心应手，也便于问题的快速定位以及项目的快速落地，一个问题卡一天，相信不少人都遇到过，而读源码、搞清楚原理，看懂别人的代码是怎么写的，对于我们自己的编码能力、设计能力、架构能力都有极大的提升。有人会说，读源码太枯燥了，没有啥意思；这里我突然想到一个问题，你读源码的时候你在想什么，这里借用村上春树在当我谈跑步时，我谈些什么里面提到的关于跑步的一句话，Pain

阿里妹导读CodeReview在日常的开发过程中越来越被重视，它在提高代码质量同时促进团队成员之间的知识共享和技能提升方面发挥了诸多作用，本文将主要围绕CodeReview展开，简单聊聊在CodeReview过程中的心得和思考。引言正如图中调侃的衡量代码质量的唯一有效标准就是CodeReview过程中WTF/min，从中可以看出CodeReview对于保障代码质量的重要性。CodeReview在日常的开发过程中也越来越被重视，它在提高代码质量同时促进团队成员之间的知识共享和技能提升方面发挥了诸多作用，本文将主要围绕CodeReview展开，简单聊聊在CodeReview过程中的心得和思考。CodeReview的重要性CodeReview是开发过程不可或缺的重要一环，如果将代码发布比作一个工厂的流水线，那么CodeReview就是流水线接近于重点的质检员，他要担负着对产品质量的保障工作，将“缺陷”从众多的“产品”中挑出，反向推动“生产方”改进生产质量。CodeReview的作用：1.改善代码质量：通过CodeReview机制，可以让团队其他同学帮忙协助把关代码质量，发现代码中潜在的质量问题，并给出改进建议，从而推动团队整体代码代码质量的提升。2.能够实现知识共享，统一认知：CodeReview过程是知识碰撞的过程，是学习别人的知识体系促进自我成长的过程，通过CR这样的过程能够将不同成长阶段的成员之间知识水位尽量拉齐，能够有效的提升团队编程的整体水平。3.能够及时潜在安全和性能问题等：通过CodeReview能够及时发现代码中潜在的安全问题和性能问题，例如：SQL注入问题、方案安全漏洞问题、部分业务场景查询实现性能较差等问题。总之，通过严格的CodeReview能够帮助团队成员养成良好的编程习惯和规范，从提高整个团队的代码质量和团队认知拉齐。CodeReview实践经验在CodeReview实验经验章节中，第一部分，将主要介绍CodeReview关注的哪些方面，通过表格的方式进行梳理和归纳；后续部分将主要围绕各个分类下的问题汇总以及从个人的视角出发提出建议。接下来，将主要围绕2个问题展开讨论：1.CodeReview应该关注那些问题；2.CodeReview问题点解读与建议。CodeReview关注哪些CodeReview关注的点比较多，这里简单做了一些归类，梳理了一部分核心关注点和场景问题。关注点分类关注点细分核心关注点常见问题代码规范与质量命名变量命名、方法命名、类命名、包命名命名拼写错误、命名与实际含义不符（超出或小于）、用词不准注释是否有注释、注释是否合理通篇无注释、注释不准确日志打印日志打印级别、日志打印参数、日志格式、异常打印、是否应该打印日志日志打印级别误用、日志参数未打印、日志格式不规范、异常信息未打印、打印日志过多异常处理异常是否抛出、是否规范的异常编码等异常该抛出未抛、肆意的使用RuntimeException等逻辑正确业务逻辑是否正常空指针问题、逻辑不正确等代码风格一致代码风格与应用整体风格一致代码风格不一致（如）代码复杂度圈复杂度大量嵌套if导致非常复杂等架构设计关注分层分层是否合理、是否存在跨层调用分层混乱、跨层调用关注扩展性扩展适配硬编码扩展性低业务域划分业务域划分清晰业务域划分混乱性能问题慢SQL索引设计、是否存在慢SQL语法索引未设计、慢SQL用法如like

阿里妹导读仅以此文，分享给那些初入职场仍在“学习与工作”之间徘徊不定的同学，或者是像作者一样已经工作一段时间却陷入迷茫的同学，希望有助于能让诸位重新迈开已经停下的脚步。如果大家有机会来北京，可以来看看工作日早上八九点钟，15号线从那座叫“顺义”的城市通向“望京”的地铁，你在那上面，能看到明明白白的，人们奔向梦想的模样。地铁上的自习室我在来北京之前，总觉得在这工作的人，是占尽天时地利的，大国之都，物华天宝，一切都透着一种贵气，哪怕连街边的豆浆油条都能比别处的贵上两块，那在这工作的人，无论眼界还是薪资，也一定就天生会比别的地方的人要高一点。可等到我来了这里，成为了北漂的开始，加入了底层打工人的大军，却发现我之前理解真的太过片面，这世间哪有什么“天生”，全是“理应”罢了，这座城市的人也不例外。这份新的理解，来自我租房搬到顺义，来阿里第一天上班坐地铁的时候，在那个咣当咣当的地上轨车厢里，是这样一份画面：“一个穿着军绿迷彩工装服的大哥坐在座位上，一只手半拎着一个尼龙包装袋，另一只手拿着一本有点黄了的书放在腿上，安安静静的在那看，偶尔抬头看看线路图；一个一看就是刚毕业不久的姑娘，在车厢门边扶着柱子，戴着一副有线耳机，看一下手机，抬起头闭一会眼嘴里嘟嘟囔囔，貌似在背什么材料；一个穿着冲锋衣脖子上挂着美团工牌带子的小哥，一手拉着吊环，一手举着个小号的Kindle，在屏幕上一会左划一下认认真真的看，偶尔皱皱眉又右划回去了，停一会又划回来；车厢里倒也没有那么安静，偶尔有两个大妈聊天聊到兴起忽然大声叽喳，但这几个人头都没待偏那么一下，孙河郊区四月早晨的阳光正好，就那么干干静静照进车厢里，而我怀着第一天来阿里上班的新鲜感，满眼新奇的观察着周围的一切，像个白痴。”后来，我在手机上下载了一些技术社区app，也为了摆正自己获取信息的渠道下载了澎湃新闻、央广新闻，也为了听一些有意思的书充了读书软件的会员，甚至于为了调换口味下载了某公开课、某词斩之类的内容，当然也少不了一台Kindle，在每一天上班的路上，慢慢重新调动起自己学习的动力，好让自己在这一间地铁上的自习室里，不要显得那么“格格不入”，不再因为无所事事而“心生愧疚”。再后来，从盲目的模仿别人在干什么，到我渐渐找到了自己适合在地铁上学习的东西，才算真正的利用起这段时间，用于潜移默化影响自己，才算明白“学习这事，从来不挑地方，也不挑时候”，也才算对得起自己“向知”这花名的初衷：生也有涯，知也无涯，向死而生，求知不怠。学习观初入职场找到成长类型刚毕业的一两年，是人成长最快的两年，这个时候的人，有朝气。啥叫有朝气？是能够对一切事物都保持足够的新鲜感，灵活的想法、勇敢地尝试、饥渴地吸收、直白的表达。在技术的道路中就是新技术探索、对想法的不断落地、技术知识的不断学习与试错，最终将这些实打实的反馈到每一次业产技的的项目需求中。尽管都是朝气，但是在实际的自我成长过程中，其实还有明显的效率上的区别的，搞清楚自己是哪种成长型，或者说对自己来说最易获得经验的方式就很重要。在今年七八月份面试校招同学的时候，我渐渐对人的成长类型有了些眉目，并在面试过程中不断地去发掘候选人是否存在明确的成长形式以来评估成长性，在我粗浅的认知看来，一个人的成长类型大致可以有这么三种：理论成长型：对技术类资料，坐得住、看得进去、吸收的比较好，技术原理理解的非常透彻，能够较容易形成知识体系，并能将源源不断的新技术归纳接入到已有的知识体系中。实践成长型：对技术实现、工程运用比较擅长的人，善于对技术的实现落地，且在每一次落地后能够有非常多的范式和方法论沉淀，不断形成明确自己的工程风格，就是那些代码越写就越好的人。经历成长型：对经历的人、事、物有独特的视角，在实际项目中，观察项目的细节、观察别人的行为、观察推进的SOP，不断树立自己对业务模式的理解、人的沟通技巧、事项落地的章法这些与实际运作有关的内容，说通俗点就是天生的PM。大部分人，其实会在这个三角形中，同时具备多个方向的特质，但是总有一个是特别明显的主要特质，会塑造一个技术人未来对外的技术角色形象，理论成长型为主的人总容易成为一名“技术科学家”，实践成长型会走向一名“技术工程师”，而经历成长型对应的形象则是“技术商人”，我在此对这三种形象的概括可能并不科学，但是足够传神了，相信大家应该能够在周围的同学找到对应的人，当然，现实生活中可能形象与形象的边界也并没有那么明显。这个时候，重点来了，当你能在这三种成长型中对应到自己的主要特质，那么就按照对应特质最高效的方式来提升自己，比如自己是个实践型的选手，那么学习技术最快的方式就是先找案例尝试实验性技术探索，遇到卡点再去查查资料，而不是找一本对应技术的底层源码原理开始阅读，对于这样的选手，原理的阅读更多的是来印证实践中的种种和梳理碎片化经验的。路子不对，苦工白费，所以适合自己的才是最好的，抓住头两年快速、高效的积累。摆正学习态度从学校刚出来的时候，最容易走入的一个误区，就是搞不清“学习和工作”的关系。往往会走向两个极端，第一种是完全学习观念，再说通俗点，就是“学生思维”转变不过来，总觉得工作就是为了获得成长；第二种，是工作挣钱观念，就是毕业了就只为了工作绩效挣钱，而忽略了自身仍需“持续学习与反思”这个技术人的安身立命之本。对于前者观念，其实更多的是一种驳斥。我常常跟师妹说的一句话“拿人钱财，替人消灾”，职场上，公司给你发工钱，买的就是你的工，是不会为了什么“让你安心学习”这种理由，或者让你做的事“有无成长价值”这种考虑，选择让你做什么工作内容。既然如此，其实并没有站位，能够完全决定自己做什么或不做什么，OKR的层层拆解也是为了各级员工更好的完成公司的目标，所以说在明面上从自身的角度，说什么“我觉得这件事没成长”这种话，甚至以此为由拒绝工作，是一种十分幼稚的行为。对于后者观念，则更多的是一种提醒。在职场上，“把结果交给雇主，但把过程留给自己”，即便很多职场技能可能最直接的目标仍是为了更好的适应职场，那么这种适应性成长，带来的薪酬回报也会是实打实的，这甚至和几十万年前不断强身健体以在打猎过程中更好的追逐猎物的人类祖先没有什么本质区别，挣钱糊口，不寒碜。尤其在现在的互联网行业里，市场和行业的变化是在不断发生的，只会端着一个碗，却不会发掘新的碗，在行业汰换的大潮中，大家吃饭的锅燃了又灭灭了又燃下一口，总有一天会饿死。尽管上述的说法太过现实骨感，可这就是真实的职场。结果才是工作的现实目的，但是可以将学习伴生在过程中，最终还是要回到“平衡”的状态。“我深知，很多时候，我们无法改变一件事要获得最终结果的诉求，但是当有机会选择获得这个结果的路径的时候，请尽量选择一条能给自己带来额外收获的路径，无论是技术沉淀、方法论总结还是认知提升，交付结果之余，让自己留有一点余温。”在工作中，尽量让自己进入正向循环：工作达成结果的过程中，找寻学习价值，良好的结果，又可以提供给下阶段工作良好的情绪价值。以此，不让自己陷入日复一日的枯燥中，不断消磨掉自己的热情，毕竟工作过程中少有能让人快乐的，但是升职加薪可以，有所习得也可以。经年有余工作几年，工作上的事轻车熟路，即便刚开始看不到明确解法，但是细细拆解也就明白需要如何行事，这是时间和经历在我们身上留下的沉淀。然而，就是在这样相对稳定的环境中，周身的事逐渐丧失挑战，世上又有那么多未知与挑战在那里，却不知该从哪开始，人往往会陷入一种迷茫，就是那种找不到“下一步”或者“下一个台阶”在哪里，应的是那句“拔剑四顾心茫然”。明知自己有了问题，却不知问题在哪里，对于这一点，其实我也很难分享什么我自己比较认可的方法论，结合自身的境遇，仅以一次对话和一个行为来分享下自己的感受。一次对话：焦虑迷茫的反义词是具体前一段时间，因为觉得逐渐对工作乃至事业热情磨灭，就跟一位朋友探讨过这件事情。朋友觉得人生的意义本就不只在工作，说我之前对待生活的态度太过潦草，下班休息在家的时候连个正经的爱好也没有，不如趁现在找个能让自己沉浸下来的爱好，准能抚平浮躁。我据理力争说我还爱玩游戏、爱盘串，也能磨炼心性，朋友说我这些东西仍是太潦草，须得正正经经系统地学点什么，才有源源不断的获得感和正反馈。笑骂完此，她表情一脸严肃，变得一本正经，忽问起我：“你现在觉得你到底是哪里有问题，是对这的工作环境不满意？还是对现在做的事不满意？还是觉得干得没意思？你总得明明白白的列出来才合理啊”，当时的我面对这个问题没有作答，直至后面她在微信上跟我发了这样一段话：“有句话我很喜欢，送给你：焦虑迷茫的反义词是具体。”“这句话我非常受益，也是那天我问你问题的方式，是希望你可以把问题和情绪具象化。因为我们无法打败看不到的敌人，只能解决具体的问题。”其实，很多时候，当我们遭遇不良状况后，从来没能进一步去分析自己到底陷入了什么问题，作为一名技术人或者工程师，我们习惯了对明确的业务问题，分析、拆解、建模、实现逐一解决的过程，却没能将这项宝贵的能力，用在解决我们自身人生的困惑中，只误以为困惑种种，不可言明。一个行为：别停下记得刚开始头一年工作的时候，那会还在上一家公司，有一次季度聊绩效，带我的大哥聊到最后跟我说：“你要记得，你现在这个时候是你成长最顺的时候，就是不断地做不断地想，千万别停下，一停就泄气了”。这话放在现在看来，不免有些PUA的嫌疑，但是即便过了这么久，我仍然觉得“别停下”这句话是适用于每个时间段的。每个人的思考方式或认知不同，我也不敢说这个观点就一定对，或许这种说法只适用于我这样的人：于我自身而言，我并不是一个十分聪明的人，我很难保证在职业发展的每一个阶段清晰的明白下一个阶段需要做些什么，陷入迷茫后，即便给我充足的时间立足自省，凭借自己的认知也难以看到一条明确的道路，每每至此，我就告诉自己先做好眼前事，边做边想，一旦有想法了就试试，觉得不行那就及时止损换一个再试，反正只要获得的体验足够的多，总会有量变引起质变的一天，别停下就对了。业务听不明白，那就厚着脸皮多问问；需求想不明白，那就找张纸先画图；代码写不明白，那就找个案例先学学；道理不懂了，那就搜书多看看书；不知道该干嘛了，那就看看身边佩服的人在干嘛。这个世界的问题，总有看上去最不聪明，但却最直白的起手点，别停下，先干干试试。有首歌唱的挺好的，“敢问路在何方，路在脚下”，路是走出来的，不是观想出来的，我特别害怕的是，当我有一天决定停下来，本意是想到特别清晰以后再走，却在长时间的停顿中不自觉地安逸起来，还美名其曰“换种心情”，而对自己身上渐渐弥漫开来的懈怠，视而不见。随时开始学习一事，从始至终。每一个阶段其实都能马上开始一门新的学问，如果觉得生活无趣，那么不如找一个新的方向，系统的学点啥，扩充下自己的能力图谱，也权当给自己找个乐子，别闲着。找自身缺憾学习最强的动力，私以为是来自于自己对自己的不满意，就是觉得不学不行了，非学不可。就比方说，很多技术人的通病，就是不太会讲话，奇思妙想都在脑子里，就是不知道怎么调理清晰的讲出来，有的时候逼急了只能来一句“我给你看代码吧”，那么为啥代码能讲明白的事，口喷就不行了呢？代码天生是逻辑的，再加上有成熟的规矩和范式约束，自然是条理清晰，但是言语这事，就是因为每天都说，反正都是人话，哪有什么听不懂的顾虑，多数人就会忽略言语的组织和范式。但是在我们这个职业场里，越到后面，“讲出来”就会变得跟“做出来”一样的重要，酒香也怕巷子深，所以一直逃着不去解决也不行，就需要系统的看一些如《金字塔原理》《沟通的艺术》这样的书籍，甚至说《乌合之众》《人性的弱点》也免不了翻翻。那么回到最开始，其实需要先明确自身的短板，不如抽时间给自己逐层画几个能力雷达图，对自己有个最初步的评估。亦或者要解决的能力不是人的发展问题，而只是职场技能的自我评估，那么也可以针对具体的场景构建一个这样的雷达。雷达图还是别的什么图不是重点，评估的问题或大或小也不是重点，重点是得真的去评估！回到前面的论点，就是要具体、要明确，你才会有个明确的目标去解决。如果你问我这玩意怎么打分，我会说凭自己的感觉就好，自满也罢不满也罢，都是自己的感觉，就算周围的人都觉得你做的不好，可你就是坚信自己是牛的，那么谁劝你学也没用；反之，明明已经在某一个圈子里登顶了，别人只配跟在屁股后头，可你自己就是觉得不满意，一直钻研，不也挺好~索性，我们生活在一个值得窃喜的时代，因为我们获得这些知识的途径多种多样，只要想要，就触手可得，但也因此大多数人是不珍惜的，但知识从不因获得途径变得容易而廉价，只会因我们的忽视与逃避而蒙尘。找自身兴趣回想一下，有没有什么一些事，是在你上学的时候说：“等以后自己上班挣钱了我就试试”。回想一下，有没有什么一些事，是你在上班的时候说：“明年的时候我一定要做做看”。回想一下，有没有什么一些事，是你在忙的时候说：“等过一阵不忙了，我就开始搞”。其实，很多时候，我们明明有兴趣、有意愿，距离一个新的开始那么的近，却被我们找一个看似合理的理由就那么推迟了，直至推迟到遗忘，然后从未开始。我的老父亲自小总告诫我，不要“常立志”，争取“立长志”，虽然直到现在我也践行的不太好，但是越长大越感叹这句话真是又对又朴实无华，当年那个流鼻涕的小屁孩，丫的怎么就听不进去呢。顺心意，在当下，即开始，别停下。适当得法善用工具说实话，我没想到我能在地铁上变着花的学习，能坚持这么久，当然，也不是一开始就能这么顺当不排斥的，各种形式的学习方式去试，后来发现太单一的知识获取形式会倦怠，得搭配着来，米饭再香，也得偶尔来碗面条。听：一开始最容易启动的方式，虽然跟多数人一样，一开始用《喜马拉雅》还是在上面听郭德纲相声助眠多一点，但后来在上班途中找书来听，尤其在那种嘈杂的地铁车厢里，带着耳机也比较清净，容易集中精神，发现每天都能有一点点小感悟，时间长了也能在写文章中略作引用。再后来，随着上面好东西逐渐开始要钱，忍痛充了一个，发现买来的东西质量是会高一些，更重要的是，钱都花了，不认真听心里觉得亏，反而是动力。完全没空间限制，有个耳机就能行，家务也行、走路也行、坐车也行、开车也行，不过不宜陷入深度思考，“道路千万条，安全第一条”。读：最简单的形式，一开始我更偏向实体书，后来发现实在是不好拿，就买了个Kindle，看的爽了一阵，后来又发现要看带图的内容，就又买了个IPadMini，为了防止自己玩游戏，还故意买了64G最小的版本，再充上一个每月19的微信读书，这一年下来，看的内容早就够本儿了~所以读书这事吧，拿啥玩意看不太重要，但是真的得看，可不能自己骗自己。写：读书的事，一开始前面看的慢，记得也多，到后来前面看的越来越多，就记不太住了，可能还是对自己的大脑的记忆力太理想化。所以想到一句老话，“好记性不如烂笔头”，于是买了一根能搭配使用的Pad笔（配合App：GoodNotes），在地铁上也能站着书写，把自己感觉重要内容和感悟实时总结和记录下来，即便过了很久记不住书中原文，翻翻笔记也可温故而知新。字迹歪歪扭扭，回头来看，想到当时在嘈杂的车厢里，心无杂念的写写画画，也觉得是一件有趣的事。我这些方式，肯定是比较土的，相信大家会有更好的方式来配合自己，形式不重要，适合最重要，有心去找一找试一试也很重要。坐得住学习，还是要得让自己坐得住。在环境中控制不住自己，就找个不需要控制的环境，有些人做事是需要先有仪式感的：地铁看不进去书，就回家再看；家里看不进去书，就找个咖啡店；咖啡店看不进去书，就找个图书馆自习室，去跟那些比自己小一轮的少年们一同学习，作为大人，还坐不住，那脸上总是挂不住的。环境、方法、工具都同理，我们是为了学习才去做这件事的，不是为了好看地学习才做这件事，不要太在乎过程是否高明光鲜，坐得住最要紧，即便你就喜欢光着膀子、扣着脚、叼根黄瓜看经史子集，只要坐得住，心够静，那就这么来。别太急功近利看书不一定立马有感悟，学习也不一定立马有收获，别太急功近利，重点是这个过程中，我们在不断的持续、在积累、在酝酿，一定要相信未来的某一天，人生的某一个瞬间，曾经的所听、所看终会化作灵感予以反馈，剩下的，无需多言。结语上班、工作、下班、休息、睡觉。在退休前的绝大部分时光，可能都是这么度过的，即便有一天从打工人变成了老板，虽然流程变得复杂，大体框架或许也仍会如此。我特别害怕未来的某一天，等到我体力跟不上，脑力也跟不上的时候，回想起这段平常的打工时光，满脑子除了那些需求项目，却想不出任何色彩，工作仅仅变成了工作，打工仅仅只是打工。所以在这个尚可改变的年纪，我希望在这段过程中里，在每一个不同的空间，每一个不同的阶段，结合自己的状态，收获一些额外的东西，让自己学习的情态变成一种习以为常，随处而栖，皆有所悟，让自己经过的时光饱含重量，等到再跟那些后来人聊起时，丰富多彩，熠熠生辉。欢迎加入【阿里云开发者公众号】读者群这是一个专门面向“阿里云开发者”公众号的读者交流空间💡

阿里妹导读本篇文章通过几个技术点说明日志记录过程中的性能实践，计算机领域的性能往往都遵循着冰山法则，即你能看得见的、程序员能感知的只是其中的一小部分，还有大量的细节隐藏在冰山之下。前言程序记录日志的过程，就是将需要记录的内容写入到磁盘文件中的过程。与生活的物流场景类似，好比是一车货物通过一套运输体系运送至目的地的过程，然而在这套物流体系中，我们往往不需要自己完成整套打包、上车、运输、卸货等全套流程，只需要将包打好之后交由专业的物流公司即可。对于我们今天所要描述的日志场景而言，日志内容是需要运送的货物，日志框架就是物流公司，而目的地就是磁盘上的文件（或其他日志收集服务器）。在

阿里妹导读如果你在做设计过程中有一些困惑，如：不会找用例、两个用例图分不清楚、不知道自己画的对不对。那么希望本文能帮助厘清上面几个问题，真正掌握用例图，在后面的设计中能运用的得心应手。在做设计的时候你是否有以下困惑？1.不会找用例：业务用例、系统用例又都是啥啊？我该如何把用例写对啊？😕2.两个用例图分不清楚：业务用例图和系统用例图感觉好像啊，似乎没啥区别啊？🤔3.不知道自己画的对不对：照猫画虎画了个用例图，但是我也不知道画的对不对，万一评审的人也不会呢，就这样交差吧🐶如果你在做设计过程中有以上困惑，那么希望本文能帮助厘清上面几个问题，真正掌握用例图，在后面的设计中能运用的得心应手。一、如何识别正确的用例首先看用例的概念，百科上定义“用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术”。什么意思呢，这里我引用《大象：Thinking

阿里妹导读代码整洁是软件长期稳定和可扩展的基础，本文作者从现实中的代码、重构、设计模式谈论代码整洁之道，总结出如何做一个有思想的程序员。我心中理想的代码软件开发是一个需要团队协作、长期维护的过程，代码整洁是软件长期稳定和可扩展的基础。整洁的代码具备清晰的代码结构和规范的命名，具有良好的可读性和可维护性，便于快速定位和修复问题，有利于新功能的快速迭代。团队成员也可以更高效地协作，减少沟通成本，整体提高项目的研发效率。首先我们可以来看下C++之父Bjarne

阿里妹导读服务一个人的系统，和服务一亿人的系统，复杂度有着天壤之别。本文从工程师文化、组织战略、公司内部协作等角度来分析软件复杂度形成的原因，并提出了一些切实可落地的解法。一、何为研发效能？当我们谈研发效能的时候，我们在谈些什么？这个议题被抛出来，有人讨论，是因为存在问题，问题就在于实际的研发效率，已经远低于预期了。企业初创的时候，一个想法从形成到上线，一个人花两个小时就完成了，而当企业发展到数千人的时候，类似事情的执行，往往需要多个团队，花费好几周才能完成。这便造成了鲜明的对比，而这一对比产生的印象，对于没有深入理解软件工程的人来说，显得难以理解，可又往往无计可施。细心的读者会留意到，前文我既用了“效能”一词，也用了“效率”一词。这是为了做严谨的区分，效能往往是用来衡量产品的经济绩效，而效率仅仅是指提升业务响应能力，提高吞吐，降低成本。这里的定义引用了乔梁的《如何构建高效能研发团队》课程材料，本文并不讨论产品开发方法，因此后面的关注都在“效率”上。本世纪

阿里妹导读日志是系统中熵增最快的一个模块，它承载了业务野蛮生长过程中的所有副产品。本文介绍了一个日志治理案例，围绕降本和提效两大主题，取得一定成效，分享给所有渴望造物乐趣的同学。前言履约管理是一个面向物流商家的OMS工作台，自从初代目把架子搭起来之后，就没有继续投入了，后来一直是合作伙伴同学在负责日常维护和需求支撑。经过几年的野蛮生长，系统已经杂草丛生，乱象百出。再后来，甚至一度成为一块无主之地，走行业共建的方式来支持。对于一个不支持行业隔离的系统，行业共建意味这个系统将快速腐化。两年前我开始接管履约管理，来到这片广阔的蛮荒之地，正如所有那些渴望造物乐趣并且手里刚好有锤子镰刀的人，我就像一匹脱缰的野马，脑子里经常会产生很多大胆且新奇的想法，希望借此把履约管理打造成一个完美的系统。只可惜真正能够付诸实践的少之又少，本篇就是为数不多得以落地，并且有相当实用价值idea中的一个，整理出来分享给有需要的同学做参考。日志乱象日志是日常开发中最有可能被忽视，最容易被滥用的一个模块。被忽视是因为打日志实在是一个再简单不过的事，前人设计好了一个logback.xml，后面只需要依样画葫芦定义一个logger，随手一个info调用就搞定，他甚至不确定这条日志能不能打出来，也不知道会打在哪个文件，反正先跑一次试试，不行就换error。被滥用是因为不同场景日志的格式内容千差万别，或者说日志打法太灵活，太随意了，风格太多样化了，以至于几乎每个人一言不合就要自己写一个LogUtil，我见过最夸张的，一个系统中用于打日志的工具类，有二三十个之多，后人纠结该用哪个工具可能就要做半个小时的思想斗争，完美诠释了什么叫破窗效应。最好的学习方式就是通过反面教材吸取教训，下面我们列举一些最常见的日志设计开发过程中的问题。分类之乱一般来说，一个系统必然需要设计多个日志文件以区分不同业务或场景，不可能所有的日志都打到一个文件里。但是怎么进行分类，没人告诉我们，于是就有了各种各样的分类。按系统模块分。这种分类应该是最基础的一种分类，也是最有层次感的分类。比如履约服务中枢的系统分层。基本上每一层对应一个日志文件。按租户身份分。一般中台系统都会支持多个租户(行业)，每一个租户单独对应一个日志文件。这种分类一般不会单独使用，除非你要做完全意义上的租户隔离。意识流分类法。不符合MECE法则，没有清晰统一的分类逻辑，按业务分，按系统模块分，按接口能力分，按新老链路分，各种分法的影子都能看到，结果就是分出来几十个文件，打日志的人根本就不知道这一行的日志会打进哪个文件。以上说的各种分类方式，都不是绝对纯粹的，因为无论哪一种，无论一开始设计的多么边界清晰，随着时间的推进，最后都会演变为一个大杂烩。某人希望单独监控某个类产生的日志，新增日志文件；新增了一个业务，比如一盘货，想单独监控，新增日志文件；发起了一场服务化战役，针对服务化链路单独监控，新增日志文件；某个业务想采集用户行为，又不想全接日志消息，新增日志文件；资损敞口的场景，需要特别关注，新增日志文件；特殊时期内产生的日志，比如大促，新增日志文件；凡此种种，不一而足。发现没有，总有那么一瞬间能让人产生新增日志文件的神经冲动，他们的诉求和场景也不可谓不合理，尽管这些日志的维度完全不相关，然而没有什么能阻止这种冲动。最开始的那一套日志设计，就像一个濒临死亡的大象，不断地被不同的利益方从身上扯下一块分去。格式之乱对于日志需要有一定的格式这点相信没有人会有异议，格式的乱象主要体现在两个方面，一个是格式的设计上，有些系统设计了非常复杂的格式，用多种分隔符组合，支持日志内容的分组，用关键词定位的方式代替固定位置的格式，同时支持格式扩展，这对人脑和计算机去解析都是一种负担。第二个是同一个日志文件，还能出现不同格式的内容，堆栈和正常业务日志混杂。来看一个例子，我不给任何提示，你能在大脑里很快分析出这个日志的结构吗？requestParam$&trace@2150435916867358634668899ebccf&scene@test&logTime@2023-06-14

启动时会初始加载所有采集配置，并支持运行过程中动态加载变更的采集配置。通过单例模式，可以有效避免多个实例间状态同步的问题；也提供了统一的全局接口，方便各个模块进行调用。class

Machine），如果能够保障每个状态机输入的是完全一致的命令序列，那么这个集合中的每个状态机最终都可以以相同状态对外提供服务，同时也具备了容忍部分状态机故障的能力。图1.

阿里妹导读本文从生活中的时间观、事件的因果顺序、逻辑时钟等方面系统的介绍了分布式系统中的时空观是如何构建的。（文末有活动～）一、生活里的时间观时间，无疑是我们观察、描述这个世界的主要手段。时间，很重要，与我们每个人的生活息息相关，不过它的本质却很难描述清楚。古代的先贤们对时间有着非常深刻的认识，《论语·子罕》一篇里有云：子在川上曰，逝者如斯夫，不舍昼夜。看来，当我们把时间和事件联系起来，便会对时间产生非常直观且具体的感受。或者说，这个让我们认识到时间其实就是事件的流逝。进一步地，如果我们不断去了解、总结各类事件发生的先后，那么就越来越接近了解这个世界的本质规律，这个也就是《大学》里提到的：物有本末，事有终始，知所先后，则近道矣。翻译成现代语言就是说，时间是用来表达、描述事件因果顺序的手段，这里的事件才是推动世界上万物演化的根本。图1.

阿里妹导读本文主要讲述了应对复杂性的一些原则和经验，通过实际案例解构设计思想，个人认为好的设计是体现在「职责分离」、「抽象分层」和「变化扩展」上，在类的结构设计上尤其要花心思去想，如「变与不变分离」、「配置域与执行域分离」、「查询与命令分离」。一、复杂是软件的本质属性1.1

阿里妹导读本文从做事方法、思维方式、目标管理、数据分析、用户增长几方面介绍了相关的方法论，希望能给读者带来一些帮助！方法论是指导做事的基本原则，能够帮助我们快速的触及问题的核心并确定解决思路，好的方法论能让我们事半功倍，下面就总结下我在阿里这几年学习到的部分方法论。做事方法论5W2H我们在做一件事时，经常需要和老板或者合作方去讲为什么要做这件事，准备怎么做，以求获得来自老板和合作伙伴的认可及支持。5W2H是指WHY、WHAT、WHO、WHEN、WHERE、HOW、HOW

阿里妹导读本文从设计原则、创建型模式、结构型模式、行为模式四个方向讲述C++的设计模式。从设计原则单一职责原则定义：单一职责原则[1]，所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。bad

阿里妹导读应用启动速度主要的瓶颈在于bean的初始化过程，本文提供了启动速度的一个探索方向。如果你的系统启动耗时250s以上，文章思路应该可以帮到你。一、背景近期，在做应用启动提速相关工作的过程中，我们发现，应用启动速度主要的瓶颈在于bean的初始化过程（init，afterPropertiesSet方法的耗时）。很多中间件bean的初始化逻辑涉及到网络io，且在没有相互依赖的情况下串行执行。将这一部分中间件bean进行异步加载，是提升启动速度的一个探索方向。二、解决方案自动扫描可批量异步的中间件bean，而后，在bean的初始化阶段利用线程池并行执行其初始化逻辑。允许使用方自行配置耗时bean以享受异步加速能力。(需使用方自行确认依赖关系满足异步条件)三、原理3.1

阿里妹导读我们对微前端框架的内容做了一个详细的介绍，并从零开始用Typescript实现了微前端的基本功能。本文我们首先实现一个可进行子应用注册和资源加载的微前端框架，实现在一个vue3主应用中加载3个不同技术栈（vue2、react15、react16）的子应用，并且页面上渲染出各个子应用的内容；然后，我们对该微前端框架实现扩展，实现运行环境隔离（沙箱）css样式隔离应用间通讯（含父子通信、子应用间通信）全局状态管理（全局store的简单使用）利用应用缓存和预加载子应用提高加载性能一、前置准备再开发我们自己的微前端框架之前，我们需要做一定的架构设计准备。我们考虑微前端架构设计时的整体思路，并画出项目架构图。1.1

阿里妹导读在日常开发中，遇到非常难以维护的页面是常态，相信不少同学也为此苦恼过，笔者在业务开发中总结了些经验希望对大家有所启发。（后台回复大数据即可获得《大数据&AI实战派》电子书）背景在日常开发中，遇到非常难以维护的页面是常态，相信不少同学也为此苦恼过，笔者在业务开发中总结了些经验希望对大家有所启发。下图是一个较为复杂的详情页、表单页，我截取了其中一小部分作为示例：随着需求不断迭代，这个页面的代码变得越来越复杂，代码达到几千行，html

阿里妹导读本文从什么是架构师PM化、架构师PM化的特点、危害等方面讲述如何防止架构师PM化。引言：什么是架构师PM化和一些做项目主架构或者一号位的同学聊天，经常会听到一种说法：项目主架构做着做着就会做成PM。这背后什么含义呢，细品下来有几层意思：1.整个集团的架构非常复杂，涉及的域众多，做主架构或者一号位需要大量的协调投入；2.不同域之间的资源错配现象严重，需要投入大量精力在锁定资源和推进排期上；3.项目结构过于复杂，PM催主架构，主架构催域架构，域架构催开发，层层订，各种站会，代码没几行，会议一大堆；4.现在做的一些项目和产品，技术含量其实是不高的，面条式架构，在架构设计和技术上的投入感觉不多。架构师PM化，其实就是脱实向虚的一种表现。架构师和PM其实都是需要对项目的进度和里程碑关心的。不同的是，PM是用表格和数字关心的进度，是没有任何实体内容的，就是一个死的燃尽图；架构师对进度的把控应该是更solid的，背后应该有架构设计和模型拆解做支撑，架构师对进度的把控是对交付物的把控，风险和进展都是有实体内容支撑的。架构师PM化的特点什么迹象可以表明架构师已经PM化或者走在PM化的道路上呢？亲力操刀的实质性工作越来越少大量参加各种评审会议和汇报，在架构方案、系分、编码、测试上的产出却越来越少甚至没有。更喜欢拉会催进度对于项目的把控在架构层面的减少，在管理层间的增多。喜欢：拉会过进度；钉钉催进度；收集进度向上汇报。越来越难直接回答问题排查问题和定位原因已经不能独立完成，需要拉各种开发同学一起。甚至于，还拉不对人，要一个拉一个。喜欢流程碰到资源和进度问题，喜欢从流程上去排期和上升，通过技术手段架构调整解决的少。架构师PM化的危害对项目的危害一个项目中有两个PM，而没有架构师的话，对项目进度的把控是很虚的，只是在例会上对各个模块开发的一个进度汇总。模块和模块之间是割裂的，风险也不太容易识别出大小和优先级。对组织的危害PM和PM之间，一定会产生踩脚，卷就来了。同时，合格的架构师会越来越少，架构的升级和演变会变得越来越困难。对架构师个人的危害架构师是一个综合的要求。项目管理只是架构师能力要求的很小一部分。如果PM化之后，架构师其他部分的能力在项目过程中就没有办法得到验证和锻炼，对业务的理解力、架构设计能力、架构落地能力、架构管控能力会逐步弱化。最终，变成一个只能做项目的PM，而失去了做架构师的基础。对研发同学的危害一个项目中的主架构如果空心化之后，是没法对开发同学形成有效的指导的。会只关注进度条的走动，而不关注开发质量和风险，一些跨域之间的架构问题可能就会下放到开发同学去讨论和决策，最终是否全局合理全局最优，很难评判。同时，主架构是项目中开发同学的一个职业模版，一个PM化的架构师，会将项目中同学的成长带偏。如何防止架构师PM化架构师PM化其实就是架构师的脱实向虚，要杜绝，需要从组织、个人和文化上采用手段。组织上要提倡做实事首先，需要在组织层面将考核体系脱虚向实，更多的看战功看产出。这个虚其实就是考察形成体系、自洽和表述的能力。我们是需要一个完美的地心说体系，还是一个有用但还不完善的日心说，值得思考。个人上要做点实事架构师需要在每个项目中落到实处去。架构方案要自己产出；架构决策一定要做而且要有记录；最好有编码；测试要参与测分和执行。文化上要对PM式的架构师说不要形成一个氛围，开发同学可以拒绝整天拉会催进度的架构师。如果一个项目中架构师架构方案和架构决策也不做，可以直接by

阿里妹导读本文主要介绍了一些主流的解析器是怎么实现like的语法逻辑，接着作者分析了几种实现方式的优劣，最终采用状态机的方式，针对场景一步一步进行性能优化。提及最近在优化项目的like语法，那既然谈到了SQL，我们不妨来看看一些主流的解析器是怎么实现like的语法逻辑。这里需要提一下主流的两种SQL解析器，它们分别是ANTLR和Calcite。ANTLR是一款功能强大的语法分析器生成器，可以用来读取、处理、执行和转换结构化文本或者二进制文件。在大数据的一些SQL框架里面有广泛的应用，比如Hive的词法文件是ANTLR3写的，Presto词法文件也是ANTLR4实现的。但是ANTLR并不会直接实现具体的语法，因此没办法找到实现语句。Calcite简化了ANTLR生成代码的过程，它提供了标准的

阿里妹导读本文作者从亲身经验阐述了一线技术人为什么述职、怎么述职以及述职的重要性。每年述职都是一大关，作者把自己的一些经验教训通过文字分享给大家，希望能帮助到更多的人。一、为什么要述职？组织需要：首先阿里是个述职文化比较浓厚的公司，基本上是一年两次述职，述职的形式各种各样：一对一的，一对多的，还见过视频直播的；述职过程一般就是述职人讲20分钟，评委问20分钟，述职效果的好坏每个组织应该都有自己的一杆秤，当然大体的评价标准大同小异。个人成长：述职对于个人来说，官方点的说法就是对自己的阶段总结、总结反思以及阶段规划什么的，不过最实在还是在个人晋升上，晋升对每个人的重要性就不说了哈，述职好坏直接影响了组织对你的评价，如果你有幸被提名了要去答辩的话，述职文档的编写能力、演讲能力、临场发挥能力，这些都非常重要了，直接影响你晋升的结果。二、述职怎么写？1、文档结构所谓的结构化思考能力一定是从一个好的文档结构开始的，优秀的文档结构基本上就已经把内容说清楚了，看内容细节只是想证实下自己的想法是否和作者想的一样而已。当然个人认为这个结构还有一个好处：以终为始的做事方式；如果下图的每一项都是一个填空题，那是不是一年里做的事按照这个图把它填满就可以了。2、概述金字塔原理：如果让你1分钟把你今年做的事给你领导汇报下，你怎么组织语言呢？如果给你10分钟呢？如果给你1个小时呢？问题的答案就在金字塔原理这本书里，其实就是把自己做的事总结抽象成一个金字塔结构，思考原则：相互独立，完全穷尽，想深入了解的建议看原书，当你把你做的事都用一个金字塔展现出来后，你只需要按照你的金字塔层次来组织语言就可以了。给你1分钟，你把第一层的事情说下；给你10分钟，你把第二层的事情再说一遍；给你1小时，把第三层的事情再说下，再举几个例子。大道至简：这里的概述其实就是当你要开始长篇大论前，请先用一分钟总结下你都干了些什么，让人有个总体的认知，如果你这个都没说清楚，后面估计别人也没心思继续听了。那概述具体写什么呢，如果是业务的话，业务结果写清楚就可以了，但这里个人认为有两个重点：归因：也就是这个结果和你个人的关系，因为这里我们说的是个人述职，既然说业务结果如果能很清晰的说出这个结果跟个人的关系，那自然是很好的，不过有的时候做的技术基建本身就是没办法归因的，譬如做了一个系统提升了小二的工作效率，但业务增长是没办法归因的，但有时候优化了接口性能，是可以带来业务效果增长的。增量：个人认为业务价值一定是要有增量部分的，业务增长有时候也是有自然增长的，如果没有合理的AB实验，那这里的增长有可能是自然增长的，而不是你这个项目带来的，所以合理的AB实验产出的数据效果，更有说服力。再来就是技术结果了，技术结果是技术人最起码的追求，也是实现自我价值最直接的东西，业务要关注归因、增量，那技术也要有关注的点，个人以为也有两点：不要造轮子：之前内网也出现过造轮子的热帖，很多大佬都有回帖，说的是慷慨激昂，我个人以为每个人心里都有杆秤，至于是选择做正确的事，还是选择当前的苟且，只有他自己才能权衡；我只能说当天平出现在我面前时，我会偏向做正确的事，但我也没办法保证在任何情况下不苟且。带来变化：今天你做了一套新的系统，或者重构了一块代码，到底带来的前后变化点是什么？个人理解变化点大致有三类：作业效率的提升、业务的增量结果以及技术先进性的提升。作业效率：这块是大部分技术在做的事，譬如把一个原本线下的流程搬到线上来了，本来需要在excel里各种操作，现在只需要在线上点几下就可以了，变化点线下变成线上了，节省了操作时间；或者把一个搜索系统的性能优化了，结果呈现从2s优化到500ms，买家可快速看到搜索结果，这样不仅提升了买家的体验，同时还能带来增量业务效果；业务增量：这个是大部分技术都想做但做不好的一块，通过技术的手段带来业务增量，这样作为技术就可以证明出自己独一无二的价值了，而不是作为资源工具人去实现PD的需求；算法的千人千面是个典型的例子，通过技术的模型预测来推算出买家的喜好商品，完全由技术算法驱动。但我还想说的是，有时候有些系统的开发跟业务效果本身真的完全没有关系，真的不要硬上，真的很没有意思，譬如你做一个活动招商系统，这个就是用来活动招商的，产品的自身定位就是为了提升小二的招商工作效率的，非要硬杠业务效果。技术先进性：这个大概就是面向未来的技术吧，上面说的都是苟且，那远方就是这个了。有可能是所在业务技术团队的缘故，看到很多这样那样的系统，技术都差不多没有太大变化，大部分人都在用最小化的方式完成当前的快速结果，但我们是不是不要那么眼前，是不是可以站的稍远一点，自己感觉下未来三年大概是什么样的，然后留下点什么不一样的东西呢！3、工作总结业务背景一切从why开始：一件事如果可以把问题定义清楚的话，那这件事已经成功一半了，看到很多新人甚至是来了好几年的同学，开始了一件事情，为啥做真的说不清楚，不知道自己为什么做，或者知道的只是很表层的原因。5W2H模式里面最重要的就是why了，why搞不清楚请不要开始。怎么搞清楚why：如果你遇到一个很靠谱的pd，她会把为什么做说的很清楚，恭喜你，你遇到了一个超级好的pd，但大部分时候我们遇到的pd，自己都不知道为什么要做，或者说的逻辑完全不通。这时候我觉得你需要自己调研清楚，否则下一步的巨坑将等着你跳。那怎么调研呢，个人理解有几个地方可以切入，第一：数据分析，尽可能多的拿到一些业务数据，分析这里面的逻辑，找数据的关联性，不过这块工作对一个后端同学来说还是挑战不小的。第二：找资料看，论坛上、各个搜索引擎、买书，最大化的扩大自己的领域知识，这样起码可以快速了解这个领域内的小白知识，不至于犯低级错误；第三：找专家问，在各个渠道找到领域的专家，谦虚的请教咨询，把自己遇到的问题都准备好问他们，看看这些高手之前遇到的坑是什么，作为自己的思考输入，起码可以站在前人的基础上继续往前走，而不是失败再来一次（不要说你比他聪明，你不会犯那样的错，no！你跟他差不多聪明）。三个why：通过以上各种输入调研素材，表事实讲道理，把问题都列出来，如果问题太多的话，建议抽象归纳成三个问题，当然三个不是绝对的。解题思考不要省略思考过程：同样看到很多人的述职文档，业务背景描述结束了，后面紧跟着就是一个系统架构设计，这就很奇怪，我并不是说大家没有思考，但是的确是没有看到，只是也许你的思考被你省略了，我想说高考作文你不思考就直接下笔吗？起码有个审题和解题路径吧。资源的权衡过程：我只想说很大一部分问题，只要能定义清楚出问题来，都是能解决的，只是在解决问题之前，需要盘一盘当前的形式以及手上的资源情况，然后给出一个最适合的ROI解决方案；这个权衡的过程其实就是解题思考，需要思考人力资源、机器资源、资金情况以及组织情况等等，这些所有的权衡过程都贯穿成一个解题路径，把这些所有的思考和权衡过程写出来，最终得出一个结论，我们要做一个什么什么样的事情，那么目标就出来了。最近看到一些大项目在如火如荼的进行中，但官方的文档里并没有这些业务背后的思考，直接一个目标，然后产品应该这样做那样做，然后结束了；也许是思考没有写，或者其他什么原因没有附上，但如果执行的人自始至终都不知道背后的思考是什么，他们怎么会有信心呢，只能自己把自己当工具人了，大概率这种项目都是要失败的。目标制定环境决定决策：业务目标由业务增长率的测算来完成，这里重点说下技术目标的设定。一句话：技术目标是围绕着业务在当前的阶段或形态来设定的。对于任何一个系统，它都有发展阶段，按照历史经验，一般的系统都会经历三个阶段：产品化、数据化和智能化，在不同的阶段技术目标一定是不一样的。举个例子：对于一个营销平台，产品化阶段一定是把这个营销平台做出来，对外需要提供营销费用的计算能力、营销氛围的统一管控、权益的传播&核销等等能力，对内需要需要搭建一个后台营销配置平台，让活动小二可以快速配置上线一个营销活动玩法，做成这样产品化阶段应该就差不多了；数据化那就要把全链路打点、AB实验能力、各种维度的数据效果看板做出来，甚至要做出一个自动化的效果数据分析能力了；智能化大多是要通过历史的营销数据做迭代反哺了，通过历史数据加业务结构化的规则建设ROI模型，在营销前期给出最佳营销费用的投入，产出最大的收益，说句简单的，就是算法模型告诉你营销应该怎么玩ROI最大化。切勿为了情怀：之前听过一个真实案例，一位同学花了两个月的时间，把一个页面接口的性能从500ms提升到100ms，页面出来的速度更快了，本来想在周会上show下自己的成果，结果反而被领导批了，领导说：对于一个网页的浏览者来说500ms打开一个网页和100ms打开一个网页有什么区别；这个故事告诉我们，不要盲目追求高可用、高性能、高扩展，所谓的三高一定是在有被需要的情况下才有意义的。技术方案面向未来的架构设计：技术目标说白了就是着眼眼前，根据眼前的情况定一个合适的目标，但在设计系统的时候绝对不是着眼当前，设计系统要面向未来。系统架构图应该怎么画，听到过一个靠谱的回答，包括四个部分：系统和外部的边界、内部组件的上下左右关系、系统的非功能性设计以及面向未来的设计，所谓的面向未来的设计，个人理解起码看到未来三年的发展形态，是抽象总结业务表层问题，看到问题背后的本质，然后把本质抽象归纳成领域模型概念，通过对领域的分析思考，产出一个面向未来的总体架构设计，其实就是多想三步，把未来的可能性都放进去。落地再次贴近现实：总体的架构设计完成后，到具体的落地环节，还是要回归到阶段目标设计里去，根据当前的资源情况产出一套落地的具体技术方案出来，这时候类似时序图、服务类图、流程图、应用关系图等等就派上用处了。这里对于这些图的详细程度标准，个人理解最好是拿到这些设计就可以直接编码的程度，千万不要等要写代码的时候，还要重新思考一遍，那就太浪费时间了。后续多次的迭代其实就是对最初那个大图的不断完善和扩展了。谈一谈技术深度：之前有一段时间，有个问题一直困惑了我很久，就是：你这个设计技术深度不够！当听到这个问题，瞬间蒙了，什么叫深度不够，多深才是深呢？10米还是100米？关于这个深度有一个衡量标准吗？当然问这个问题的人，他也没解释清楚什么叫深度，我当时真有点感觉他在pua我，但是我还是带着这个问题日思夜想，终于得到了一个自己觉得稍微有点满意的答案。技术深度其实可以用某一领域的专业技术壁垒来解释，说到深度是在某个精细化的领域下，通过长时间的沉淀积累或者遇到特殊场景下的复杂问题，总结出一些专属在这个领域场景下的技术方案，我觉得这可以称作为技术深度。至于复杂问题我说明下，多复杂叫复杂？这其实也不好量化，说的简单点，当你提出一个领域问题时，对于大部分的普通技术专家来说，他无法在短时间内给出解决方案，那么我认为这就是复杂问题（当然不排除天才级别的瞬间能想出办法来）。当然我再重申一句，千万不要为了技术深度而过度设计，只是当我们遇到了有技术深度特点的事，我们知道怎么去判断并很好的表达出来。结果说明这里的结果逻辑思考路径跟概述里是差不多的，但区别是这里的表达可以更细致一些。譬如业务数据可以把具体的计算公式列出来、AB实验对比的时间维度列出来等等；技术结果可以把概述里面沉淀的平台扩展开来，详细说明下里面的核心模块、扩展性，甚至是横向方面的一些内容都可以，譬如性能、稳定性、安全方面等等。总结反思总结思考本质上和解题思考是前后呼应的，一件事情在一个阶段结束后，一定是有做的好的和做的不好的地方，做的好的大大方方的写出来，特别优秀的数字和战绩完全可以标红加粗，做的不好的也大大方方的写出来，千万不要说今天只有Highlight没有Lowlight，这个是绝不可能的，任何系统在不同的阶段和环境下总有问题，只是组织在权衡了利弊后，选择是否要去解决它而已。其实Highlight在前面的概述和结果说明里大体都提到了，这里重点还是要说下Lowlight，说句比较实际的话，没有这里的Lowlight，下个阶段的规划怎么写呢？4、个人成长&团队贡献灵魂拷问的启蒙：之前有一次分享，整个过程中的我滔滔不绝，一切尽在掌握中的感觉，结束后到了Q&A环节，有个前辈问了我一个问题：“你这个系统挺厉害了，但现在假如由于组织调整，必须要把你这个系统交给别人来做，你怎么看？”，当时第一反应就是：“我做了这么长时间，付出了这么多，马上就要收割了，你让我交给别人，肯定不干啊，强行拿走，我就辞职。”，当然那种场子肯定是场面话应付过去了，譬如尊重组织选择啊、拥抱变化啊什么的，但没等我说话，前辈紧接着又是一个问题：“如果你现在做的这套系统承接的业务没了，业务被砍了，你怎么办？”，说实话当时脑袋瓜嗡嗡的，脸很烫，自己从来没有思考过这种问题，完全不知道怎么回答，后面只能说会后再思考下这个问题。可迁移的个人能力：其实这个问题背后的逻辑就是个人成长问题，如果你的系统交给了别人，或者你的业务没有了，那就给呗，没有就没有了，互联网产品的变化本来就是这样瞬息万变的，重点是你在做这个系统的过程中，自己在哪些方面得到了成长，是架构设计能力、数据洞察能力还是结构化思考能力，这样的能力提升是伴随着你一生的，是刻在你脑袋里的，没有人可以拿走，这个才是属于你自己真正的财富。前段时间有个同学问我，个人成长都有哪些呢，我大概写几个大家参考下：组织协调能力、数据洞察能力、项目管理能力、复杂系统架构能力、团队管理能力、结构化思考能力、沟通能力、演讲能力等等，大家可以拿这些能力对照下自己，哪些方面比较弱，可以给自己定一个财年目标，今年重点训练哪几个。之前听过一个人，把这种能力定义成叫可迁移的能力，这些能力是不分行业不分工种，每个人在职场都应该不断完善丰富自己的这种底层基础能力，假如哪一天互联网落寞了，换个行业你也可以快速适应下来。关于团队贡献：我认为其实本质上还是在于个人成长上，只是在你成长的某个阶段你需要把你的成长外化出来，通过各种形式表达出来，通过文章的形式写出来，通过在各个地方（团队内、bu内、bu外、集团外）分享告诉更多的人，也可以针对创造性的技术点写专利、论文，这些都是不同的渠道而已，重点是要输出，成长其实就是输入和输出的过程，费曼学习法也是这样的逻辑，输入后一定要有输出，你把不明白的人说明白了，你才是真正的明白了。当然通过这些外化的形式也可以带来个人品牌影响力的提升，至于个人品牌的重要性就不多说了，大家自行想象。5、财年规划看一个人对一块业务的理解程度，只要问他对这块业务的下一年规划是什么就够了，如果需要更深入的话，就问三年规划。要回答这问题其实非常难，首先要知道业务的定位是什么，整个组织给这块业务的位置在哪，需要完成什么样的历史使命，核心的衡量指标是什么，核心的领域问题本质是什么，当前处于一个什么样的外部环境，核心的业务&技术问题有哪些，这些问题的优先级是什么，问题应该怎么解决，别人是怎么解决的，别人&自己的优势&劣势有哪些，当前的资源怎么组织可以最大化的解决这些问题，有没有更好的解决方案，如果有需要哪些资源的配置，落地的节奏是什么，需要哪些团队配合，有哪些风险等等这样的问题，当然如果这些问题都想明白了，那真的是想的很明白了。其实在上面一些小节中已经说了同样的一些内容了，当前的形式环境下一定是有新的问题，透过问题找本质，面向未来做设计，把其中的逻辑说的足够自洽其实就已经超过80%的人了，后面只需要一些文字功底、画图能力以及演讲技巧，把问题表达清楚其实就可以了。写在最后最近一年自己组织了一个新人学习小组，看到了很多新人遇到的一些这样那样的问题，有时候他们是真的不知道，在成长中遇到各种各样的困惑，在这个过程中通过个人的努力也得到一些同学的正反馈，属实有点欣慰，原来帮助别人得到反馈是这么幸福的，所以把自己的一些算经验教训吧通过文字分享给大家，希望能帮助到更多的人，这也许就是稻盛和夫「心」这本书里说到的「利他」的幸福感吧，感恩。关于你述职的那些事儿欢迎在下方留言区分享你述职的经验或者在述职过程中遇到了哪些问题，获得点赞第一位读者将会获得定制水杯一个哦～活动截止日期：2023年3月17日。期待大家的经验想法👏

阿里妹导读本文用实际用例阐述了用心组织的代码也能让性能提升百倍，我们不应该停留在CRUD的漩涡中。下面来看看这个神奇的现象。一、震惊，这代码居然有差别！CPU友好的代码与我们平时的那些CRUD操作可能没啥关系。但是用心组织的代码其实也能让性能提升百倍。我们不应该停留在CRUD的漩涡中。今天我给大家带来一个很神奇的现象，文章不长，原理通用，还请大家耐心看完！我们可以先看下面的矩阵计算。大家也可以自己思考一下，如果是你来实现一个矩阵的乘法，你会怎么来做。下图是我给出的A、B、C

阿里妹导读目前go语言不仅在阿里集团内部，在整个互联网行业内也越来越流行，本文把高德过去go服务开发中的性能调优经验进行总结和沉淀，希望能为正在使用go语言的同学在性能优化方面带来一些参考价值。前言go语言凭借着优秀的性能，简洁的编码风格，极易使用的协程等优点，逐渐在各大互联网公司中流行起来。而高德业务使用go语言已经有3年时间了，随着高德业务的发展，go语言生态也日趋完善，今后会有越来越多新的go服务出现。在任何时候，保障服务的稳定性都是首要的，go服务也不例外，而性能优化作为保障服务稳定性，降本增效的重要手段之一，在高德go服务日益普及的当下显得愈发重要。此时此刻，我们将过去go服务开发中的性能调优经验进行总结和沉淀，为您呈上这篇精心准备的go性能调优指南。通过本文您将收获以下内容：

阿里妹导读引入消息队列可以帮助我们解耦业务逻辑，提升性能，让主链路更加清晰。但是消息链路的代码腐化和一致性问题也给业务带来了很多困扰，本文阐述了钉​钉审批消息链路重构的设计和解决方案。注：Metaq

的负责人嗷嗷（首页的前前任主管），他说『如果你要做就把性能提升一倍，要不然就别做了』。于是我又找了释然（首页前任的主管），他说『好啊，那你就做到第一』。这时我就更加郁闷了，天猫首页首屏基本是一个大

和云原生技术对基础设施和工作负载层面的抽象逐渐统一的态势下，如何进一步简化和标准化应用交付与管理层面的操作和功能，成为接下来一个非常自然但重要的演化方向，也会成为市场真正需要角逐的战场。2019

阿里妹导读目前全球范围内手语老师严重不足，调研各种情况后我们开发了一款产品希望帮助听障人士解决一些生活中的常见问题，本文将为大家分享虚拟数字人《手语翻译官》的技术实现。背景用户规模世界银行的数据显示，全球大约有

阿里妹导读本文介绍了什么是操作符重载、为什么需要操作符重载、如何在Java中实现操作符重载以及一些建议。什么是操作符重载操作符重载，就是把已经定义的、有一定功能的操作符进行重新定义，来完成更为细致具体的运算等功能。从面向对象的角度说，就是可以将操作符定义为类的方法，使得该操作符的功能可以用来代表对象的某个行为。为什么需要操作符重载我们来考虑实现这样的功能：使用

concern）。比如，Istio服务网格通过Sidecar实现应用网络流量拦截与转发，监控代理通过Sidecar实现对业务应用的数据采集等等。我们可以将过去部署在每个节点上的基础设施agent

阿里妹导读把《重构：改善既有代码的设计》这本书推荐给已经接触了工程代码、工作一年左右的新同学，相信有了一定的经验积累，再结合日常项目实践中遇到的问题，对这本书的内容会有很多自己的思考感悟。前言很久之前团队师兄向我推荐了《重构：改善既有代码的设计》这本书，粗略翻阅看到很多重构的细节技巧，但当时还处于未接触过工程代码，只关注代码功能，不太考虑后期维护的阶段，读起来觉得枯燥无味，几乎没有共鸣，一直没有细细阅读。在工作一年后，终于在师兄的督促下，利用一个月左右的早起时光读完了这本书，收获很多，感谢师兄的督促，感谢这本书陪伴我找回了阅读习惯。把这本书推荐给已经接触了工程代码、工作一年左右的新同学，相信有了一定的经验积累，再结合日常项目实践中遇到的问题，对这本书的内容会有很多自己的思考感悟。一、重构的定义书中给出了重构的定义：对软件内部结构的一种调整，目的是在不改变软件可观察前提下，提高其可理解性，降低其修改成本。每个人对重构有自己的理解，我理解的重构：重构是一种在不改变代码本身执行效果的前提下，让代码变得更加整洁易懂的方式。代码不仅要让机器能够实现预期的处理逻辑，更要能够面向开发人员简洁易懂，便于后期维护升级。二、为什么要重构我对书中的一句话印象很深刻，“减少重复代码，保证一种行为表述的逻辑只在一个地方出现，即使程序本身的运行时间、逻辑不会有任何改变，但减少重复代码可以提高可读性，降低日后修改的难度，是优秀设计的根本”。回想在刚毕业工作不久时，我也曾对同组师兄的代码重构意见有所疑惑，重构本身可能不会改变代码实际的执行逻辑，也不一定会对性能产生优化，为什么一定要对代码的整洁度、可复用性如此执着？结合书中的答案以及自己工作中的体会，主要有以下几点：2.1

阿里妹导读你是否会困惑一场汇报或者一些知识的总结该如何进行，或者你已经有了一些总结，但是还并不知道该如何结构化的组织它们，这个时候就可以采用金字塔结构进行组织。背景无论是一次简单的汇报还是对于自己的学习过的知识的进行相应的总结，我们的信息要素总是没有经过结构化总结的。你是否会困惑一场汇报或者一些知识的总结该如何进行，或者你已经有了一些总结，但是还并不知道该如何结构化的组织它们，这个时候就可以采用金字塔结构进行组织。《金字塔原理》核心知识点脑图梳理金字塔原理一共出版了两本书分为理论篇和实战篇，本文章是对第一本书理论篇进行重点知识的总结与引导，其中第一本书的1-9章还是纯理论的，10-12偏实战的。（清晰大图请在后台回复“金字塔原理”获取）金字塔结构是怎样的条理清晰的文章所表达的各思想之间有明确的逻辑关系，组成总体上的金字塔结构。但是部分人开始总结写作的时候还只有模糊的想法，所以必须梳理自己想表达的思想。纵向关系上纵向关系能够很好的吸引读者的注意力，并且通过总线关系可以引导一种疑问/回答式的对话。横向关系上下一层次的表述必须保证能够回答上一层次上的表述所引起的疑问，同时保证表述符合逻辑。一般在横向关系的表述上，采用演绎推理或者归纳推理，后面会介绍到这两种推理的形式。还要一个序言虽然金字塔结构可以与读者不断的疑问/回答进行对话，但是如果内容跟读者没有相关性很难吸引读者的注意力，这个时候就要有序言。序言的开头应向读者说明“背景”的时间和地点，在这“背景”中应当发生了某件事情，一般称为“冲突”，使读者提出你的“解决方案”的疑问。这样可以使读者和你站在同一位置上。如何构建金字塔结构自上而下自上而下的构建方式的流程图第一步

formatThreadLocal.get();format.parse(str);2、使用java.time.DateTimeFormatterJDK8

阿里妹导读本文主要针对Vue开发者或新手快速上手React。本文主要分析Vue和React在开发上的区别，帮助Vue开发者快速上手React，同时也适用于前端新手入门React。单文件组件

进行重新聚合）。第三方性能/可靠性测试日志采集是整个日志基础设施中最基础最关键的组件之一，影响着企业内部数据的完整性以及实时性。采集器作为数据链路的前置环节，其可靠性、扩展性、灵活性以及资源（CPU

阿里妹导读本文基于两个出发点，描述了业务平台于21年12月启动了对JDK版本升级的适配之路，并回顾了整个升级过程，对升级过程中的问题做了记录。业务平台升级JDK11，基于两个出发点：一、jdk8于2019年1月停止维护，springboot2.1之后的版本已经兼容JDK11，springboot3.0完全放弃对JDK8的支持，未来属于更高版本的JDK；二、在试点国产化芯片的过程中，由于JDK8对Arm架构的优化不足，导致国产化芯片无法发挥自身的性能优势，为了更好的适配国产化，务必要求对JDK版本进行升级。基于上述两个出发点，业务平台于21年12月启动了对JDK版本升级的适配之路。这里回顾整个升级过程，对升级过程中的问题做一下记录。一、升级版本的选择当时有两个JDK版本可供选择，JDK11、JDK17，从长远来看，JDK17更代表未来，但由于JDK11

背景在企业的商业活动中，订单是指交易双方的产品或服务交易意向。交易下单负责创建这个交易双方的产品或服务交易意向，有了这个意向后，买方可以付款，卖方可以发货。在电商场景下，买卖双方没有面对面交易，许多情况下需要通过超时处理自动关闭订单，下面是一个订单的流程：如上图所示，一个订单流程中有许多环节要用到超时处理，包括但不限于：买家超时未付款：比如超过15分钟没有支付，订单自动取消。商家超时未发货：比如商家超过1个月没发货，订单自动取消。买家超时未收货：比如商家发货后，买家没有在14天内点击确认收货，则系统默认自动收货。一、JDK自带的延时队列JDK中提供了一种延迟队列数据结构DelayQueue，其本质是封装了PriorityQueue，可以把元素进行排序。把订单插入DelayQueue中，以超时时间作为排序条件，将订单按照超时时间从小到大排序。起一个线程不停轮询队列的头部，如果订单的超时时间到了，就出队进行超时处理，并更新订单状态到数据库中。为了防止机器重启导致内存中的DelayQueue数据丢失，每次机器启动的时候，需要从数据库中初始化未结束的订单，加入到DelayQueue中。优点：简单，不需要借助其他第三方组件，成本低。缺点：所有超时处理订单都要加入到DelayQueue中，占用内存大。没法做到分布式处理，只能在集群中选一台leader专门处理，效率低。不适合订单量比较大的场景。二、RabbitMQ的延时消息RabbitMQ的延时消息主要有两个解决方案：RabbitMQ

Fabric侧重技术，通过各种组件构建统一元数据、联邦计算引擎、智能的数据编排消费探查工具实现面向业务人员的统一开发和管控平台，数据也是分散在各个存储计算引擎，从技术上也可以作为支撑Data

架构的核心是管理复杂度，架构师的核心能力是抽象能力，什么是抽象能力？抽象能力就是一种化繁为简的能力。何为化繁为简？就是把一种复杂的事情变得简单的能力，比如通过打比喻让别人很容易听明白你说的意思就是一种抽象能力。如何锻炼抽象能力？我觉得有三种方法，第一种是用归纳法找共性，从多个问题中找到共同的问题提炼通用解决方案，去其糟粕取其精华。第二种通过演绎法找关系，从多个问题中找关系，把多个问题串成一个问题，系统化解决问题！第三种是通过归纳法找特性。化繁为简需要不断的思考，不断的看清一件事的本质，这个事的解决方案越容易。一、通过归纳法找共性通过归纳法找共性有两种方法，分别是找需求的共性和找信息的共性。1.1

缘起重新理解云计算，这个「重新」重点是对我自己而言的。有这样的感受是来源于几个触点：第一个触点是阅读了两篇非常有见解的文章，分别是道哥的《我对计算的理解》和吴军的《中国算力的危与机》；第二个触点是最近阅读了王坚院士的《在线》这本书；第三个触点是阿里云内部的AEPC考试，对阿里云产品体系有了一个更加全面完整的了解。这三个触点学习下来，发现自己对云计算的理解还是很浅薄。借助本篇文章，以「输出倒逼输入」串联一下这三个触点的学习和思考内容，作为总结。云计算，云是一种形态，其关键在于计算。计算离不开算力。但算力和计算是两个东西。因此理解云计算需要先清楚两个东西，一个是算力，一个是计算。云计算实际上也是一个关于算力的产业。阿里云成立之初就有一个信念：计算作为一种公共服务。基于这个信念确定了最初的愿景：让整个数据中心等于一台计算机，这也是阿里云一直做的事情，提供更强大的算力的基础设施。因此，如果以算力产业的角度透视阿里云，阿里云过去一直做的事情是：不断建设和提升算力基础设施的规模、优化算力管理效率、提供足够多的算力产品和应用来解决计算便捷性问题。以这个视角看阿里云在云计算领域的发展过程，更容易构建起整个阿里云的产品体系的大局观，这也是这篇文章想尝试做的事情。算力的演进什么是算力？从狭义上看，算力是设备通过处理数据，实现特定结果输出的计算能力。2018

数据分析的语言接口OLAP计算引擎是一架机器，而操作这架机器的是编程语言。使用者通过特定语言告诉计算引擎，需要读取哪些数据、以及需要进行什么样的计算。编程语言有很多种，任何人都可以设计出一门编程语言，然后设计对应的编译器做解析。编程语言从分类上来说，可以分为命令式，声明式。命令式编程语言是我们最常见的编程语言，C/C++/Java等都是命令式编程语言，这类语言明确的告诉机器应该执行什么样的指令，留给编译器优化的空间很小了。声明式编程描述程序应该获得什么结果，至于如何做到，并不关注细节。SQL就是一种声明式编程语言。例如SQL语句select

引导用户去设置能耗策略、开启通过前台服务，实现更好的保活效果。单纯从手机App出发进行保活有较大的局限性，这也促使车企和手机厂商合作（宝马和苹果、理想和荣耀等）：蓝牙配对介绍The

前言本文从最原始的需求出发，结合需求变化，推导出用户系统的演进。（如果有理解偏差之处，还请谅解，欢迎讨论）（故事纯属虚构）一、创业老王是程序员，出去创业了，做当下最火的web3.0，需要做app和web，第一步需要一个用户登录功能，这对老王来说简单。用户可以拿邮箱或者手机注册，填一些基本信息（如名称、性别、年龄等），初始化密码，提交后给用户生成平台唯一id。用户可以拿手机或者邮箱登录，设计如图，搞定了。二、新增需求-三方登录产品经理提出为了方便用户快速注册，借助当前用户量最大的平台，实现授权登录，授权登录后经过用户授权从大平台那里拿用户基本信息（手机号，邮箱等等），避免用户注册耗时原因导致用户放弃注册的流失。安全同学也提出了，有可能用户邮箱泄露，黑客拿着邮箱来调用平台的登录服务暴力破解密码，需要限制验密错误次数以及冻结功能等。老王想了想，简单，在模型中扩充一些字段就可以解决。把市面上比较火的平台id都预留一下，免得后面一个一个加；同时在把验密失败次数或验密失败时间记录下来，一旦达到一定次数，就不允许调用登录服务。三、新增需求-用户类型区分由于业务的发展，用户不在局限于个人用户，一些公司也需要入驻进来，显然，年龄、性别等信息就不再适合给公司用户使用了，到这里，模型必须要拆分了。老王希望把模型拆成继承关系，用户表作为父类，可以延伸出公司用户和个人用户，如下图所示。四、业务扩张了老王的创业公司发展迅速，开始融资了，不仅nft搞得如火如荼，还要搞某币交易。某币交易涉及到金融（我们假设老王创业的地方监管环境允许），那么需要进行实人（实体）认证，需要知道用户在法律意义上到底是谁。这里的需求，已经不是纯用户角度了，而是知道你的客户是谁，已经开始向客户系统演进。另外由于涉及到某币账户操作，因此需要搞一个交易密码，现在很多设备都支持指纹和人脸了，产品希望指纹和人脸也能支持。老王接到了以上需求，他开始思考以下几个问题：密码：现在密码种类变多，从登录密码扩展了交易密码；另外交易密码可以支持普通密码、指纹密码、人脸等子类型。登录方式：之前的设计太粗暴了，扩展性很差，之后如果要支持身份证登录，或者营业执照号登录，都需要再加字段。实人（实体）认证：真实世界的人或者企业，与之前系统模型中的用户是一个概念吗？假如没有监管的要求，之前用户模型里边的信息，就可以支撑用户在平台上的各种使用诉求（登录、信息显示等等）。4.1

2023玉兔迎春，再启新章阿里开发者祝大家新春大吉，大展鸿“兔”新的一年希望与各位开发者携手同行，奔赴热爱！

Review方法论与实践总结关于技术能力的思考和总结是什么让一段20行代码的性能提升了10倍谈谈我工作中的23个设计模式从Redis7.0发布看Redis的过去与未来

什么是扩展方法扩展方法，就是能够向现有类型直接“添加”方法，而无需创建新的派生类型、重新编译或以其他方式修改现有类型。调用扩展方法的时候，与调用在类型中实际定义的方法相比没有明显的差异。为什么需要扩展方法考虑要实现这样的功能：从

Sandbox的入门使用基本上讲完了，上文提到了一些JVM技术名词，可能小伙伴们听过但不是特别了解。这里简单阐述几个重要的概念，理清楚这几个概念之间的关系，以便大家更好的理解JVM

流系统，如何轻松设计？』这三篇文章。钉钉也将自己沉淀多年的消息系统架构实现做了分享，可以阅读『5亿用户如何高效沟通？钉钉首次对外揭秘即时消息服务DTIM』这篇文章。大数据存储架构传统大数据架构是