摘要：
关于架构师的成长之路，还存在着一个误区，就是把架构师默认为软件架构师。因为今天我们所遇到的架构师，大多数都是围绕着软件研发。事实上这个认识有一定的片面性。诚然，现今我们所构建的系统都是软件系统，但是在实际的工作过程中，随着信息技术在深度和广度上的快速发展，除了软件研发以外，测试、网络、安全、配置、系统和数据都已经形成了具有自己独特专业知识和经验的领域，也都需要各个领域的架构师。比如信息安全是一个非常专业的领域，要软件架构师无法完全理解和驾驭信息安全是勉为其难。网络架构师日常研究的各种网络问题，软件架构师也难以置喙，因为这是完全不同的两个领域。数据方面亦如此，能够把整个公司业务数据之间的关联性了然于胸的人，一个公司或许能有一两个，这种人就是数据架构师。现实的情况是，软件架构师占据主导地位，基本上掩盖了其他领域架构师的光芒。当然出现今天这种情况的主要原因也是因为大部分的技术领导者也都是来源于研发领域。这种状态要尽快改变，否则在运维、安全、数据、测试等其他领域工程师很难有自己的成长空间。 阅读全文
摘要：
平时听到一些同学说技术方案没什么深度，很难讲出来，怎么去体现技术方案设计的深度是大家普遍关心的一个问题，这个问题不是个例问题，因此分享下自己的一些观点和看法。主要从三个部分来讲：
第一部分主要分析为什么技术方案没有体现出深度，找到问题后就好解决，并提出技术方案的广度和深度特征；
第二部分是技术方案设计的方法论，主要包括了本质论、矛盾论、系统论、演进论四个方法论，构成一个闭环反馈链路；
第三部分是通过具体的案例，反复运用第二部分的方法论阐述在实例的案例中如何去应用，加深对方法论的理解。 阅读全文
摘要：
高级程序员是一名犯过其领域内所有可能犯到的错误的专家。
如果按照工作经验对软件开发人员进行分类，可能是这样的：
初级：2-3 年工作经验
高级：10 年以上工作经验
中级：介于初级和高级之间
这种按工作年限的分类存在一个问题。那就是：它对软件开发的质量只字未提。在工作的那些年里你到底获得了多少经验和技能？这正是面对开发人员的求职和面试如此复杂的原因。度量技能是很困难的，所以我们在面试中给开发人员进行了很多有难度的测试。但这些测试充其量也只是了解一个大概，无法度量其究竟具备多少完成该项工作所需的经验或专业技能。 阅读全文
摘要：
导读：成为一名架构师可能是很多开发者的技术追求之一。那么如何理解架构？架构师是一个什么样的角色，需要具备什么样的能力？在架构师的道路上，会面临哪些挑战？本文作者道延分享他对架构以及架构师的思考和相关实践，希望对同学们有所启发。 阅读全文
摘要：
导读：作为一个技术TL（Team Leader），除了自身技能，还会面临诸多团队管理上的困难和挑战。如何定义和明确团队的目标？怎样建立优秀的工程文化？让团队长期发挥战斗力和创新能力的核心是什么？本文作者基于四年的团队管理经验，分享他在招聘、目标管理、团队沟通和工程文化等方面的思考与总结，介绍相关的经验方法，并推荐几本关于体验、思考的书籍。希望对同学们有所启发。 阅读全文
摘要：
在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。 阅读全文
摘要：
本文详细介绍了我国银行核心系统的定义、位置与边界，发展历程、更换核心系统的原因，以及新核心建设的五大模式与其特点对比。希望内容能够帮助银行科技从业者建立起对银行核心系统的整体认知，提供一定积极的指导作用与借鉴意义，从而引发思考并促进行业交流与探讨，共同为我国的银行科技蓬勃发展贡献自己的智慧与经验。
在这里，特别要感谢张广老师，对我国银行核心系统的发展历程部分进行了完善和补充，特别是关于目前业内流行的分布式微服务组建模式，学到很多。希望后续有更多的小伙伴来分享自己的见解或想法，一起思维碰撞，探索更多可能…… 阅读全文
摘要：
1）对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2）应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。 3）应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引 阅读全文
摘要：
今天我们来聊一个老生常谈的话题，跨域！又是跨域，烦不烦 ？网上跨域的文章那么多，跨的我眼睛都疲劳了，不看了不看了 🤣 别走...我尽量用最简单的方式将常见的几种跨域解决方案给大家阐释清楚，相信认真看完本文，以后不管是作为受试者还是面试官，对于这块的知识都能够游刃有余。 阅读全文
摘要：
就像在学习之前先要识字，我想在介绍优化 JavaScript 代码之前，先介绍一下自己对编程语言的理解。故事要从一只叫做 Theseus 的机械鼠和其发明人克劳德-香农（Claude Shannon）说起。在传记《A Mind at Play：How Claude Shannon Invented the Information Age》中，作者 Jimmy Soni 和 Rob Goodman 强烈希望将香农的作品 Theseus 展示给广大读者。面对复杂的迷宫，Theseus 仅用一堆继电器、ROM 存储等简单而古老的电子元器件，就完成了对复杂迷宫的探索和成功线路的记忆，第二次沿着正确道路走出迷宫的 Theseus 没犯一点儿错误。大多数人认为这不过是骗人的把戏和小玩意儿，弃之如敝履。少数聪明人眼里 Theseus 蕴含的惊人智慧简直可以和牛顿、爱因斯坦媲美，香农凭借一己之力将布尔代数引入电子电路设计启发了后世数字电路乃至计算机的发明。 阅读全文
摘要：
技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。本文作者阿里巴巴技术专家三画，分享了自己和团队在画好架构图方面的理念和经验，首发于阿里内部技术分享平台，梓敬、鹏升和余乐对此文亦有贡献。 阅读全文
摘要：
这篇文章主要整理了一下计算机中的内存结构，以及 CPU 是如何读写内存中的数据的，如何维护 CPU 缓存中的数据一致性。什么是虚拟内存，以及它存在的必要性。如有不对请多多指教。 阅读全文
摘要：
在我看来并不是MVC的基础上增加领域层，使用充血模型，解耦基础服务，我的代码就符合DDD了。
为什么要使用DDD?
DDD分为战略部分跟战术部分，相信大家都认同DDD的核心在战略而非战术。而战略方面的核心我认为在业务建模，领域划分、统一语言等都在为业务建模服务。
为什么业务建模重要?
以前的开发流程有什么问题？
先说结论，开发人员交付的程序对业务方，产品人员，测试人员来说就是一个黑盒子。除了开发人员自己，没人知道盒子里有什么。当新的需求加入来，需求方，产品人员，甚至测试人员都认为可行，开发人员却给出相反结论。 阅读全文
摘要：
导读：面对多种多样的跨端诉求，有哪些跨端方案？跨端的本质是什么？作为业务技术开发者，应该怎么做？本文分享阿里巴巴ICBU技术部在跨端开发上的一些思考，介绍了当前主流的跨端方案，以及跨端开发的经验心得。 阅读全文
摘要：
随着前端的范畴逐渐扩大，深度逐渐下沉，富前端必然带来的一个问题就是性能。特别是在大型复杂项目中，重前端业务可能因为一个小小的数据依赖，导致整个页面卡顿甚至崩溃。本文基于Quick BI（数据可视化分析平台）历年架构变迁中性能的排查、解决和总结出的“个性”问题，尝试总结整个前端层面相对“共性”的问题，提供一些前端性能解决思路。 阅读全文
摘要：
本文的重点在于说明工作中所使用的设计模式，为了能够更好的理解设计模式，首先简单介绍一下业务场景。使用设计模式，可以简化代码、提高扩展性、可维护性和复用性。有哪些设计模式，这里就不再介绍了，网上很多，本文只介绍所用到设计模式。 阅读全文
摘要：
上个月我写的一篇文章《关于技术能力的思考和总结》引起了大家的关注，好多读者的评论“以写代想、以想促真、以讲验真”，大家的感受很深刻，基于上次的文章，这篇文章我其实更想跟大家聊聊一些常用的思考方法，思考问题的方式对了，往往可以帮助大家少走弯路。 阅读全文
摘要：
在写开源项目的时候，想到了要支持多种redis部署方式，于是对于这块的生产环境的架构选型展开调研。
推荐使用更新的引擎版本以支持更多的特性，
Redis 6.0新特性说明
模块系统新增多个API。
支持SSL/TLS加密。
支持新的Redis协议：RESP3。
服务端支持多模式的客户端缓存。
支持多线程IO。
副本中支持无盘复制（diskless replication）。
Redis-benchmark新增了Redis集群模式。
支持重写Systemd。
支持Disque模块。 阅读全文
摘要：
安全是产品的底座，是体验的基础，也是企业的一项核心竞争力。安全生产是一项系统性的工作，同时也是一件比较琐碎的事，需要做方方面面的考虑尽一切可能保障系统安全稳定运行。个人之前一直负责商品的稳定性工作，在这方面有比较多的经历和实践。
记得在18年的时候，我们做商品发布的组件化改造，当时正好碰上网站刚开始类目调整，一度连续3个月每个月都有故障，当时稳定性的压力很大。当然那也是一个契机，商品的稳定性建设也是从那个时候开始起步，然后逐步的完善。 阅读全文
摘要：
Web 水印技术在信息安全和版权保护等领域有着广泛的应用，对防止信息泄露或知识产品被侵犯有重要意义。水印根据可见性可分为可见水印和不可见水印（盲水印），本文将分别予以介绍，带你探秘 web 水印技术。 阅读全文
摘要：
内卷告诉我们，表面的精细、复杂、讲究不等于高级，更不等于先进，那只是一种自欺欺人的假象，一种黑暗中无知的消耗，一种悲哀的精神寄托。只有跳出圈圈，站在更高层次上的不断向外突破、创新和创造，才能不让那种精致的、繁复的、看起来特别敬业的内卷化状态困扰我们，才能回归到向上勃发的新常态上来。
明白了内卷的含义，大家便可以有意识地避免陷入内卷，减少内卷造成的浪费和伤害。 阅读全文
摘要：
工作中总是遇到数据存储相关的 Bug 工单，新需求开发设计中也多多少少会有数据模型设计和存储相关的问题。经过几次存储方案设计选型和讨论后发现需要有更全面的思考框架。
日常开发中常用的存储方案选型很多都是 “拿来主义” 的，凭借着经验、习惯选用，但对它们的细节特性或约束少有研究。
除了手边会用的存储方案，也应该关注市面上更合适的存储方案。
一定的技术预研和储备能够帮助未来更好的技术方案设计。
故写了这篇文章，抛出我的观察和思考，希望日后可以将一些更先进 (合适) 的技术引入公司业务，助力业务发展。 阅读全文
摘要：
弹性伸缩是云计算时代给我们带来的一项核心技术红利，但是 IT 的世界中，没有一个系统功能可以不假思索的应用到所有的场景中。这篇文章，我们将应用企业级分布式应用服务-EDAS 的客户在进行系统架构设计时，在弹性场景下遇到的点滴做了一个系统的梳理，总结为五个条件和六个教训分享给大家。 阅读全文
摘要：
一个单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行校验。
单元测试几乎都是用单元测试框架编写的；只要产品代码不发生变化，单元测试的结果是稳定的。
为什么需要单元测试
在我看来，单元测试的意义可以总结如下三点：
单元测试是保证你写的代码是你想要的结果的最有效办法
单元测试帮我们塑造设计
单元测试是最好的文档之一
单元测试描述了代码的预期行为，可以最有效地保证代码正确运行，减少代码缺陷；由于单元规模较小，当因为代码变更出现问题的时候，可以帮助我们快速定位问题；有单元测试覆盖的代码，让我们更有信心，敢于放心做代码重构；
写单元测试的过程往往伴随着代码重构，如果发现一段代码单元测试很难写，就需要反思我们的设计，进而重构促进代码设计的优化，帮助我们塑造设计；
同时单元测试也是一个最佳的、自动化的、可执行的文档；没有单测覆盖的代码，是很难被维护的。 阅读全文
摘要：
Serverless 架构将成为未来云计算领域重要的技术架构，将会被更多的业务所采纳。进一步深究，Serverless 架构在什么场景下有优秀的表现，在什么场景下可能表现得并不是很理想呢？或者说，有哪些场景更适合 Serverless 架构呢？ 阅读全文