varyall的专栏

转载 SpringCloud的限流、熔断和降级——Hystrix

在分布式系统中，远程系统或服务不可避免的调用失败（超时或者异常）。假设客户端依赖多个服务，在一次请求中，某一个服务出现异常，则整个请求会处理失败；当某一服务等待时间过长，则所有的请求都会阻塞在这个服务的请求上。这样因为一个服务就导致了整个系统的可用性。Netflix的组件Hystrix可以将这些请求隔离，针对服务限流，当服务不可用时能够熔断并降级，防止级联故障。认识Hystrix在理想状态...

转载 Synchronized的原理及自旋锁，偏向锁，轻量级锁，重量级锁的区别

在多线程并发编程中Synchronized一直是元老级角色，很多人都会称呼它为重量级锁，但是随着Java SE1.6对Synchronized进行了各种优化之后，有些情况下它并不那么重了，Java SE1.6中为了减少获得锁和释放锁带来的性能消耗而引入的偏向锁和轻量级锁，以及锁的存储结构和升级过程。 锁从宏观上分类，分为悲观锁与乐观锁。乐观锁乐观锁是一种乐观思想，即认为读多写少，遇...

转载 【算法】(查找你附近的人) GeoHash核心原理解析及代码实现

分享提纲：　　0. 引子　　1. 感性认识GeoHash　　2. GeoHash算法的步骤　　3. GeoHash Base32编码长度与精度　　4. GeoHash算法　　5. 使用注意点(曲线突变--8个邻居来解决)　　6. geohash的php 、python、java、C#实现代码　　7. 参考资料 引子机机是个好动又好学的孩子，平日里就喜欢拿着手机地图点点按按来查询一些好玩的东西。某一...

转载 mmap和常规文件操作的区别

mmap和常规文件操作的区别对linux文件系统不了解的朋友，请参阅我之前写的博文《从内核文件系统看文件读写过程》，我们首先简单的回顾一下常规文件系统操作（调用read/fread等类函数）中，函数的调用过程：1、进程发起读文件请求。2、内核通过查找进程文件符表，定位到内核已打开文件集上的文件信息，从而找到此文件的inode。3、inode在address_space上查找要请求的文件页是否已经缓...

转载 B+树与LSM树的区别与联系

首先来回答一个问题：为什么在磁盘中要使用b+树来进行文件存储呢？原因还是因为树的高度低得缘故，磁盘本身是一个顺序读写快，随机读写慢的系统，那么如果想高效的从磁盘中找到数据，势必需要满足一个最重要的条件：减少寻道次数。我们以平衡树为例进行对比，就会发现问题所在了：先上个图 这是个平衡树，可以看到基本上一个元素下只有两个子叶节点  抽象的来看，树想要达成有效查找，势必需要维持如下一种结构：树的子叶节点...

转载 linux内存映射mmap原理分析

一直都对内存映射文件这个概念很模糊，不知道它和虚拟内存有什么区别，而且映射这个词也很让人迷茫，今天终于搞清楚了。。。下面，我先解释一下我对映射这个词的理解，再区分一下几个容易混淆的概念，之后，什么是内存映射就很明朗了。 原理首先，“映射”这个词，就和数学课上说的“一一映射”是一个意思，就是建立一种一一对应关系，在这里主要是只 硬盘上文件 的位置与进程 逻辑地址空间 中一块大小相同的区域之间的一一对...

转载 mysql insert锁机制(insert死锁)

一、前言上周遇到一个因insert而引发的死锁问题，其成因比较令人费解。于是想要了解一下insert加锁机制，但是发现网上介绍的文章比较少且零散，挖掘过程比较忙乱。本以为只需要系统学习一个较完全的逻辑，但是实际牵扯很多innodb锁相关知识及加锁方式。我好像并没有那么大的能耐，把各种场景的加锁过程一一列举并加之分析；亦没有太多的精力验证网上的言论的准确性。只好根据现在了解的内容，参考官方文档，说说...

转载 高级进阶：复杂业务系统的通用架构设计

结合着业务系统的复杂性，如果想要系统未来具有长期价值，不得不把大的系统进行拆分，用统一的业务语言进行描述，把不可识别的问题，拆分成可识别的问题域进行解决，这也就是现在又逐渐盛行起来的领域驱动设计的方法。应用如何进行设计，包括模块如何划分，功能如何实现，技术如何支撑，数据如何展示，流程如何定义，逻辑如何实现，数据如何存储等等，都是应用架构的范畴。架构的本质依然没有改变，只是由于社会的发展，我们的需求，需要处理的问题、依赖愈来愈复杂，我们需要用发展的眼光，时刻追随技术前沿，进而推进、优化、迭代系统的架构设计。

转载 TOGAF 企业架构介绍(4A架构)

1、信息（数据）架构定义：数据架构是企业架构的一部分，企业级数据架构是以结构化的方式描述在业务运作和管理决策中所需要的各类数据及其关系的一套整体组件规范。企业架构主要包括业务架构、信息/数据架构、应用架构、技术架构四大部分。业务架构明确定义企业的治理结构、业务能力、业务活动、业务数据。企业架构是战略和实施之间的桥梁，业务变革的关键使能，是设计IT的基础，如果缺少企业架构，那么数字化转型的战略、目标和落地、执行之间将脱节。企业架构主要包括业务架构、信息/数据架构、应用架构、技术架构四大部分。

转载 架构评审的步骤和方法

架构评审是一个系统的过程，旨在确保软件架构满足系统的当前和未来需求。。在准备评审阶段，重点是了解项目的业务目标、收集相关文档并组织评审团队。这个阶段至关重要，因为一个充分的准备工作可以为接下来的步骤打下坚实基础。

转载 分析TOGAF架构和4A架构的区别和相似点

2、关注点不同：TOGAF更加注重企业整体架构的设计和实施，包括业务架构、数据架构、应用架构和技术架构等方面。3、强调架构的重要性：两者都认为企业架构是企业成功的关键因素之一，因此强调架构的重要性，并提供了相应的工具和方法来支持架构的设计和实施。TOGAF架构和4A架构都是企业架构的方法论和框架，它们在定义、设计、实施和管理企业IT系统方面具有相似之处，但也有一些区别。1、都是企业架构的方法论和框架：TOGAF和4A都是提供一套完整的企业架构方法论和框架，用于指导组织设计和构建其IT系统。

转载 系统架构评估方法

这一步涉及ATAM评估过程的描述。在此步骤中，评估负责人向所有相关参与者提供有关ATAM过程的一般信息。领导者说明评估中使用的分析技术以及评估的预期结果。领导者解决小组成员的任何疑虑、期望或问题。在这一步中，提到了系统体系结构驱动程序的业务目标。这一步着重于系统的业务视角。它提供了有关系统功能、主要利益相关方、业务目标和系统其他限制的更多信息。在这一步中，架构团队描述了要评估的架构。它侧重于体系结构、时间可用性以及体系结构的质量要求。此步骤中的体系结构演示非常重要，因为它会影响分析的质量。

转载 【架构专题】架构评估方法论：ATAM与SAAM的深度解析与实践指南

但这一过程面临三大核心挑战：多维度质量属性冲突（如性能与安全的博弈）、动态业务需求适配性（每年平均需求变更率达47%）以及技术债务的累积效应（每拖延1年修复成本增加4倍）。ATAM（Architecture Tradeoff Analysis Method）由SEI于2000年提出，是SAAM的升级版本，其核心突破在于构建质量属性效用树（Utility Tree），将抽象的质量目标转化为可量化评估的指标。结语：在数字化转型浪潮中，ATAM与SAAM已从单纯的评估工具演变为架构治理的核心引擎。

转载 架构评估模型有哪些

每个模型都有自己的特点和适用情景。在实际应用时，组织可以根据自己的特定需求和期望解决的问题选择合适的评估模型。通常情况下，多模型联合运用可以更全面地进行架构质量评估。可行性评估、性能分析、维护成本估算和安全性检查，都是创造成功软件系统不可或缺的评估方面。最终，这些评估都是为了确保软件架构能在不断变化的环境需求中保持自身的优势和持久性能。通过选择合适的架构评估模型，组织能够更好地识别风险，做出明智的决策，并构建一个既可靠又可持续发展的软件系统。相关问答FAQs：Q: 什么是架构评估模型？

转载 架构权衡分析方法（ATAM）

能揭示架构如何满足特定的质量需求，还能提供分析这些质量需求之间的交互作用的方法。理解架构设计满足系统质量需求的结果。

转载 后台服务架构高性能设计之道。

如我曾经写过一个线程安全的容器以放置各种对象时，为了减少锁争用，对容器进行了分段，每个分段一个锁，按照哈希或者取模将对象放置到某个分段中，如 Java 中的 ConcurrentHashMap 也采取了分段的机制。严格来说，各种池都是对象池模式的应用，包括前面的这三哥们。

转载 robbin谈管理：改造团队的经验

一般来说新官上任三把火，新的高管空降之后往往会大肆招人，快速推进改革。但我在入职之前就考虑过这个问题，以为宜缓不宜急，理由如下：1、做为空降高管，在公司没有任何根基，亦没有做出任何成绩来证明自己，这个时候领导的信任和授权是有限度的。一旦初战不利，领导的信任度被透支，在公司恐怕难有立足之地，更遑论改造团队，发挥自己的才能了。2、我早年做过很多软件咨询项目，给很多公司讲过敏捷开发、领域模型、面向对象建模和ORM。但我能够得到这些公司的信任，却并非因为讲这些时髦的内容，而是因为擅长解决各类技术上的疑难杂症

转载 robbin谈管理：改造团队的经验（1）

1、刚接手一个有问题的团队，不着急上来烧三把火，要先对整个团队做深入的调研，搞清楚整个团队的核心问题在哪里，团队的组成架构和运作方式，团队每个成员的特点和能力，他们之间的关系，要彻底的摸清楚这个团队过去成功的地方和失败的地方，具有的优点和存在的问题。写出来我对每个员工的印象和评价。因为后来我看到过类似的案例，空降的高管在没有对业务深入了解，对团队能力没有深刻认识的情况下就从外面急吼吼招来了新的主管，结果新主管的业务能力和现有团队匹配不上、配合不好，造成了新主管和老团队的尖锐对立，团队搞得一团糟。

转载 2、刚接手一个新团队要做什么？

很多新任管理者，太急于表现自己，忘了全局性思考，做出的决策都是具体而且片面的，必然会出问题。4、修炼格局：当你负责一个团队，你要选择战斗的高效，还是战役的高效，这是一个格局问题。每个带团队的人，尤其是新管理者，必须提升自己的格局，只有这样才知道怎么打仗。管理者要有深度思考问题的耐心，管理者最宝贵的资源是头脑，要多动脑，少动嘴。了解下属的问题、困惑和需要；你的评价和绩效来自于上司，你要有足够的耐心和诚意，向上司了解团队的主要情况。3、凡事预则立：要想成就一件事，必须要有明确的目标，认真的准备和周密的安排。

转载 经验分享：如何在接手新组织后进行团队整合

在整合团队的过程中，刚开始在不了解实际情况的条件下尽量保证原有团队的稳定，最初几个月要提目标要求和工作标准，能达到要求的留用，达不到要求的逐步更替。对事情的评价往往比对人的评价更准确。实际工作中，经验不足的企业负责人或HR容易抓不住重点，在团队负责人没有到岗的情况下开始直接确定下面的具体岗位和招募具体人选，往往不符合业务的要求，或者人选与后来的团队负责人配合不好。所有的访谈获得的信息和评价都或多或少带有一定的主观性，不如直接布置几件具体的事情让其干，通过事情的结果和过程中展示的思维和方法论对其进行评估。

转载 在腾讯做架构设计的15大原则与6个避坑思维

框架和架构的区别还是比较明显的，框架关注的是“规范”，架构关注的是“结构”。架构是经过系统性地思考，权衡利弊之后在现有资源约束下的最合理决策，最终明确的系统骨架：包括子系统、模块、组件，以及他们之间协作关系、约束规范、指导原则，并由它来指导系统各方面的设计和指导团队中的每个人思想层面上的一致。业务架构是战略，应用架构是战术，技术架构是装备。在 TOGAF9 是这么定义：一个系统基本的构件（子系统，模块，组件），体现在它的各个构件、构件间的相互关系、构件与环境间的关系，以及对系统设计和演进进行治理的原则中。

转载 搞懂架构之业务架构、数据架构、技术架构

技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm 等），这些运行组件之间的关系，以及部署到硬件的策略。紧接着业务模式越来越复杂，订单、商品、库存、价格等各个模块都很深入，比如价格区分会员等级，访问渠道（app 还是 PC），销售方式（团购还是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，需要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的服务化架构，即微服务。划分组件的主要目的的是单元复用。

转载 毛选：任何长久的关系，都是反人性的

在《湖南农民运动考察报告》里，他观察群众，不是怂恿他们忍，而是给出战略性压力释放方法，让他们敢斗敢争，敢面对现实、认清敌我，走出困局。真正长久的关系，是你愿意忍，但你忍之后，依然会提醒对方、修复规则，甚至带着羞涩说出你受伤。你不觉得可怕，是因为你不曾真正感觉到被对方理解、被对方接受、被对方继续选择——这才是长久关系里，反人性的珍贵。真正长久的关系，从来不是你想象的那样温柔，而是在冲突、矛盾、不理解之间，被重新定义和重生。感动只是短期资源，真正长久的情感和信任，是被机制重建，被情绪清理，被价值体系承载。

转载 如何进行系统架构评审：全面指导与实践

架构师向评审团队介绍架构设计方案，包括设计目标、主要组成部分、关键技术选择等。回答评审团队成员的初步疑问和关注点。

原创 能力成熟度模型/中台成熟度模型

已定义级:已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程,所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。level1:孵化期，level2:定制开发，level3:服务化，level4:自助化，level：商业化。level5:商业化，用类SAAS模式的解决方案对外售卖，具备清晰的商业模式和完善的服务流程，直接创造收入。初始级 :.软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。80%+中台需求不需中台开发，l3和l4，

转载 【架构】软件成熟度模型与评估体系深度解析

成熟度模型的核心理念是通过定义一系列阶段性的目标和标准，引导组织系统性地提升其能力水平，最终实现可预测、高效和高质量的软件开发。ISO/IEC 33000系列是ISO/IEC 15504的后续标准，提供了更加模块化和灵活的过程评估框架。通过系统性地实施和持续改进成熟度模型，组织可以显著提升软件开发能力，构建持续创新和高质量交付的竞争优势。CMM发布（1991年）：由SEI（软件工程研究所）发布的能力成熟度模型。国际标准化（2003年）：ISO/IEC 15504（SPICE）的发布。

转载 为了提升代码质量我做了哪些努力？

在这个人兼多责的社会里，我显得那么的特立独行，殊不知，现在社会上发生的很多事情都是因为没有处理好职责导致的，比如，经常有些父母带着小孩，一边玩手机，导致小孩弄丢、发生事故等等。

转载 软件研发效能度量指标——交付速度

综上所述，通过科学运用交付速度度量指标，软件研发团队能够精准定位效能瓶颈，制定有效的改进策略，实现持续的效能提升。针对低效环节或短板指标，深入剖析原因，制定针对性的改进措施，如优化工作流程、引入自动化工具、加强技能培训等，并在实施后重新度量，验证改进效果。在深入探讨如何利用这些交付速度度量指标提升研发效能之前，首先需要强调的是，任何单一指标都无法全面反映一个复杂系统的全貌，因此，应当采用综合分析的方式，结合多种指标进行多维度评估，并理解各指标间的相互关联与影响。

转载 如何快速增加需求吞吐并缩短交付周期？

业务侧要有定期的业务规划和更新，产品侧要定期规划和更新产品目标、产品路线图，以及排好顺序的产品待办列表。资深开发人员或者架构师提前识别技术可行性，以及用户故事之间的依赖，并在发布计划和迭代计划的时候明确如何解决依赖，包括：依赖跟踪负责人、要解决完成依赖项的责任人、范围和时间等。特别是依赖其他敏捷开发团队的接口定义、数据结构定义、数据格式或者数据库定义等，以及用户体验和交互设计师的一些视觉稿或者设计，尽量在迭代前或者迭代中并行准备好。组建端到端、可以独立交付的、面向价值流的敏捷团队进行迭代开发。

转载 进度管理的业绩怎么写好

进度管理业绩的核心是“用数据证明你让事情变得更可控”。从目标拆解到危机处理，每一环节都需指向可衡量的改进。工具（如PingCode/Worktile）是辅助，真正的竞争力在于你如何通过管理动作创造业务价值。相关问答FAQs：如何有效撰写进度管理的业绩报告？在撰写进度管理的业绩报告时，首先需要明确报告的目标和受众。有效的报告应包括项目的关键里程碑、完成的任务、遇到的挑战及其解决方案。此外，使用图表和数据可以帮助更直观地呈现进度，确保信息清晰易懂。有哪些关键指标可以用于评估进度管理的效果？

转载 系统重构的10点经验总结

说到系统数据有些同学可能仅仅关注的是业务数据，其实数据也包含了系统运行所产生的日志数据，无论新旧系统的日志数据，都是很重要的，如果因为重构影响到数据的读取、处理、分析，则是得不偿失的事情。导读：我们日常工作中，系统重构应该是最让人头疼的了，无论是错综复杂还是简单的系统，在发展的过程中都会经历重构，系统重构也是任何技术团队无法回避的问题，在我服务的多家公司，几乎每家公司都经历了一次甚至多次系统的重构，本文就我在多年的重构工作中总结出来的几点建议分享给各位朋友，希望能够给朋友们带来帮助。

转载 【转载】大型系统架构重构10步法

任何系统在持续的演进迭代的历程中，都难免因各类因素导致迈向重构，比如：系统可塑性与业务需求无法匹配、扩展性无法支撑业务体量的膨胀、技术债务引发研发效率的严重下滑等。稳定性要求高的系统必须可回滚，无法回滚等于飞蛾扑火（笔者职业生涯至今所经历的重构项目，上线完全符合预期且不需优化的情况，都没达到 ...）。业界调研尽量覆盖国内外大厂、公司内部的同类产品的情况（比如在不了解某领域业界最优能力是 T 的情况时，目标随意定为 T+，就很不现实。明确并量化目标，这是方案选型的基础，也是确保演进路径清晰的必要条件。

转载 【腾讯】7张架构图掌握后端服务重构技巧

重构是项目发展中不可避免的一环。关键在于把握重构的核心要点：首先明确重构的目标并集中解决关键问题，其次确保在重构过程中维持“功能一致性”和“数据一致性”。这样做可以使整个重构过程更加流畅，并确保重构带来的收益远大于其成本。重构过程中，明确重构目标如引入新功能、性能提升、增强系统可用性等是前提条件，此外也必须考虑功能一致性和数据一致性这两大关键问题。3️⃣逻辑与存储模块联合重构：同时升级业务逻辑和数据存储结构。1️⃣逻辑模块重构：专注于优化代码逻辑和业务流程。2️⃣存储模块重构：改进数据存储和检索机制。

转载 MongoDB和Elasticsearch的对比

MongoDB和Elasticsearch都是我比较喜欢的存储产品两者的功能特性也存在很多重合的地方, 其实现在很多数据库产品都在互相借(chao)鉴(xi), 功能和特性都在逐渐变得相似, 这也是未来很多存储产品的发展趋势, 大家都希望自己能覆盖尽量多的场景和用户群体很多产品总是在不断的从没有->有->功能丰富,但是功能丰富一定是做了很多的妥协, 于是又有了功能众多的单体服务->多个功能单一的子服务方向的转变,就像三国里面说的 “天下大势, 分久必合合久必分”.

转载 奥卡姆剃刀原则

奥卡姆剃刀原则是指在系统设计和开发中，如果某种技术A已经能解决特定问题，且另一技术B也能解决相同问题，则应优先考虑仅使用其中一种技术，以避免不必要的复杂性和维护成本。这一原则源自于哲学家奥卡姆的威廉提出的“如无必要，勿增实体”（Entities should not be multiplied beyond necessity）的原理，其核心思想是：在解释相同现象时，应优先选择最简单的解释，因为简单的解释通常更有可能接近真理，并且更容易验证和应用。

转载 如何做技术选型

与其焦虑框架迭代，不如夯实架构根基：头发会掉，代码永生。优秀技术选型如同打理发型——匹配当前发量（团队能力），预留植发空间（扩展可能）。修饰脸型（业务场景），

转载 系统稳定性建设三件事

一、背景2024年初，我接手了团队的稳定性负责人工作。从接手时的生疏和不熟悉，到开始学习稳定性工作、构建思路、落实方案，面对问题不断反思再推进，现在也积累了一些经验，借此机会总结一下。二、稳定性定义为了做好系统稳定性建设，首先需要明确什么是系统稳定性。通俗来说，系统稳定性指的是在经历外部干扰导致偏离原有平衡状态后，系统仍能在干扰消失后具备自主恢复到原来平衡状态的能力。这种能力体现了系统的韧性和恢复力。明确了稳定性的定义，下面将详细说明建设之初我所遇到的问题及挑战。三、问题、挑战及期望目标。

转载 如何对系统进行重构设计？

原文链接：https://blog.csdn.net/yaoqiancuo3276/article/details/147543661。我主导了架构重构方案，从需求出发进行现状评估，并基于领域模型进行系统拆分，最终设计为分层 + 微服务架构；在我们公司原有系统为单体架构，随着业务扩展，遇到性能瓶颈、部署效率低、扩展困难等问题；如果你在阅读过程中有任何问题，或者想了解更多技术细节，请在评论区留言，我会尽快回复。支持未来业务发展：如需要支撑更高并发、分布式部署、多租户、多端接入等；未来业务增长点：用户量增长？

转载 TOGAF的架构模型

原创 架构总结记录

敏捷开发：是部分开发，挑重点开发，因为开发是局部，不能统筹全局，所以当下的架构就会失效，出现代码腐化。不可避免的代码腐化是指在软件开发过程中，由于需求的不断迭代、技术债务的累积以及维护不善等原因，代码质量逐渐下降，变得难以理解和维护的现象。不可避免的代码腐化是指软件开发过程中，由于需求的不断迭代、技术债务的累积以及架构设计的局限性，代码质量逐渐下降的过程。该分离的分离，该提取的提取，进行逻辑抽象，功能封装，能力下沉，多系统复用。腐化除了来自开发者低质量的代码，更核心的是来自于系统架构的腐化。