华仔爱技术-CSDN博客

原创为什么我说“设计模式”的设计理念是误人子弟？

很多人都学过设计模式，但是大部分人却被设计模式带偏了，乱用设计模式、滥用设计模式、炫技式的应用设计模式，把代码写的更乱了，原因不是23个设计模式本身有问题，而是设计模式背后的设计理念有问题。

2021-12-30 09:00:53 991 1

原创 Mac平台Sourcetree使用Personal Access Token踩坑全纪录

github更新安全访问协议后，Sourcetree只能使用Personal Access Token接入，但是mac平台上不是简单的改改Sourcetree就可以了，而需要更复杂的操作，本文记录了这个踩坑和填坑的过程。

2021-12-19 20:32:13 2051

原创 MTTR、MTBF、MTTF、可用性、可靠性傻傻分不清楚？

MTTR、MTBF、MTTF、可用性、可靠性的正确理解

2021-12-02 12:41:49 30154 7

《碟中谍》系列电影中，汤姆克鲁斯主演的亨特特工，无论什么情况，什么环境下都能够有惊无险的完成那些看似不可能的任务。对于技术人员来说，如果也能像汤姆克鲁斯那样，不管什么mission impossible最后都能解决，那迎娶白富美，当上CTO，走向人生巅峰都不是问题！“异地多活”看起来就是这样一个万能的大杀器，很多人理想中认为只要实现了“异地多活”，不管是新奥尔良水灾，美加大停电，蓝翔挖掘机。。。。...

2016-11-25 17:09:31 5333

原创大牛养成指南（3）：天天写业务代码，如何成为技术大牛？

不管是开发、测试、运维，每个技术人员心理多多少少都有一个成为技术大牛的梦，毕竟“梦想总是要有的，万一实现了呢”！正是对技术梦的追求，促使我们不断地努力和提升自己。然而“梦想是美好的，现实却是残酷的”，很多同学在实际工作后就会发现，梦想是成为大牛，但做的事情看起来跟大牛都不沾边，例如，程序员说“天天写业务代码还加班，如何才能成为技术大牛”，测试说“每天都有执行不完的测试用例”，运维说“扛机器接网线敲

2016-09-30 14:02:42 9092 3

原创大牛养成指南（2）：先实现一个小目标吧！10000小时理论如何轻松落地

1000小时理论虽然简单，但时间持续很长，是一个大目标，如何将10000小时理论分解为一步一步可操作可执行的行动呢？本博客给出了答案

2016-09-30 13:48:09 7229 4

原创大牛养成指南（1）：吃的草够多，你也能成为大牛

“如何才能成为大牛”，这个问题很多人都问过我，我会写一个系列来回答“如何成为大牛”这个问题，这是第一篇，是拉勾理想之上广州站活动的现场演讲稿。主要讲1000小时理论以及如何找到10000小时

2016-09-30 11:28:51 8994 13

转载 BAT解密：互联网技术发展之路（10）- 运维平台技术

本来想自己写一篇运维体系的文章的，但毕竟不是专业运维人员出身，担心讲的太肤浅，因此转载我的好朋友王金银（江湖人称老王）同学发表在InfoQ的运维体系介绍。老王的牛逼相信很多同学已经领教过了，全球运维技术大会深圳站一个人专场讲运维能讲3个小时，而且会场还爆满，更多老王的介绍可以参考文章的最后，也可以关注老王的微信公众号：互联网运维杂谈。

2016-08-01 12:36:09 6408

原创异地多活设计辣么难？其实是你想多了！

有幸参与了阿里游戏的一个高可用方案的设计，并且在网上发表了方案（面向业务的立体化高可用架构设计），后来参加GOPS全球运维大会深圳站，与众多行业高手交流，发现大家对“异地多活”这个方案设计非常感兴趣，毕竟“异地多活”的方案价值非常大，尤其是互联网行业，规模稍微大一点几乎都必须是标配；但同时大家都觉得“异地多活”的方案设计又很难，网络、数据、事务等各种问题混杂在一起，很多问题看似是无法解决

2016-08-01 09:51:40 5151

原创给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（4）—— 文武双全

【文武双全】前面讲了那么多，看起来都是和项目管理相关的的，例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。。。。。架构师怎么变成了项目经理了，说好的技术呢？真正的架构师，当然必须具备一定的项目经理技能，但更重要的还是技术能力，道理很简单：再好的饼，最后实现不了，都是扯淡！我将“项目管理能力”称之为“文”的能力，“技术能力”称之为“武”的能力，架构师必须文武双全，才能最终把事情搞定！

2016-06-02 09:31:37 7524 2

原创给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（3）—— 运筹帷幄

【运筹帷幄】一般来说，需要架构重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。可以想象一下，假如我们拿到一个架构问题列表，其中有50个问题，那我们应该怎么去

2016-05-27 15:25:44 7316

原创给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（2）—— 合纵连横

【合纵连横】【合纵】架构重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免的会影响业务功能的开发。因此，要想真正推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通。注意这里我不是指要谈办公室政治，而是指要和利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和争执。道理很简单，但如何做才是关键！一般的技术同学谈到架构重构的时候，就

2016-05-24 20:24:04 7046

原创给飞驰的法拉利换引擎 - 谈边做业务边做架构重构（1）——有的放矢

序言对一个程序员来说，世界上最痛苦的事情是什么呢？有的人会说：编码的时候产品改需求！有的人会说：看别人不知所云的代码！有的人会说：定位一个百年不遇千年难寻的线上不定时偶尔出现的bug！有的人会说：找不到女（男）朋友！。。。。。。。。。。。。。。。。。。。。。。。。。。但我要说，这些痛苦其实都不算什么，要么是多花点时间去解决（比如说改需求、看代码），要么是多花点心思（比如说找另一半、定位疑难bug）

2016-05-18 10:15:00 6157

原创 BAT解密：互联网技术发展之路（9）- 业务层技术剖析

互联网的业务千差万别，不同的业务分解下来有不同的系统，所以业务层没有办法提炼一些公共的系统或者组件，但抛开业务的差异，各个互联网业务发展最终面临的问题都是类似的：就是复杂度越来越高，也就是说，业务层面对的主要技术挑战是“复杂性”。幸运的是，面对业务层的技术挑战，我们有一把屠龙宝刀，神挡杀神，佛挡杀佛，不管什么业务难题，用上屠龙宝刀一试都迎刃而解。这把屠龙宝刀就是“拆”。复杂性的一个主要原因就是系统

2016-04-29 19:22:52 17427

原创使用开源项目的正确姿势，都是血和泪的总结！

软件开发领域有一个流行的原则DRYDon’t repeat yourself我们翻译过来更形象通俗不要重复造轮子。开源项目主要目的是共享其实就是为了让大家不要重复造轮子尤其是在互联网这样一个快速发展的领域速度就是生命引入开源项目可以节省大量的人力和时间大大加快业务的发展速度何乐而不为呢然而

2016-03-03 10:07:11 10649 9

原创 BAT解密：互联网技术发展之路（8）- 用户层技术剖析

互联网业务用户层技术主要包括：用户管理、消息推送、存储云、图片云。用户管理互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来，因此用户管理是互联网业务必不可少的一部分。稍微大一点的互联网业务，肯定会涉及到多个子系统，这些子系统不可能每个都自己来管理这么庞大的用户，由此引申出用户管理的第一个目标：SSO，单点登录，又叫统一登录。单点登录的技术实现手段较多，例如cookie、token等，

2015-12-31 17:04:42 5355

原创面向业务的立体化高可用架构设计

为了实现阿里九游游戏接入系统的业务高可用，技术人员跳出传统的面向系统的高可用的思路，转而从业务的角度来整体考虑高可用，最终实现了一套立体化的高可用架构，本文逐一展示这套立体化高可用架构的一些具体实践。

2015-11-16 15:59:47 7027 1

原创 BAT解密：互联网技术发展之路（7）- 网络层技术剖析

上一篇博文《BAT解密：互联网技术发展之路（6）- 服务层技术剖析》中，介绍了互联网业务发展特点的中的“复杂性”的应对方式，本文介绍互联网业务发展特点的另外两个方面“高性能”、“高可用”。一般人提到高性能时第一想到的就是优化，提到高可用时第一反应就是双机或者备份，但是对于互联网这种超大容量和访问量的业务来说，这两个手段都是雕虫小技，无法应对互联网业务的高性能和高可用需求，互联网业务的高可用和高性能

2015-11-11 15:14:00 7030 3

原创 BAT解密：互联网技术发展之路（6）- 服务层技术剖析

在系列文章的第2篇“BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，当系统的数量增加到一定的程度，就由复杂度量变带来了复杂度的质变，主要体现在系统间相互依赖程度加深：比如说为了完成A业务系统，可能需要B、C、D、E等十几个其它系统进行合作。从数学的角度进行评估，可以发现系统间的依赖是指数级

2015-10-13 15:51:51 21100 16

原创 BAT解密：互联网技术发展之路（5）- 开发层技术剖析

剖析互联网技术开发层相关技术和主流的做法，包括开发框架、web服务器、容器技术

2015-06-02 15:20:58 7772 4

原创 BAT解密：互联网技术发展之路（4）- 存储层技术剖析

剖析互联网技术存储层典型的做法和方案，包括SQL数据、NoSQL数据、小文件、大文件

2015-05-29 17:48:40 7877 3

原创 BAT解密：互联网技术发展之路（3）- 牛逼公司的技术架构都是这个范

大部分人对于BAT的技术有一种莫名的崇拜感，觉得只有非常牛逼和天才才能做出现在的这些系统，但经过前面两篇博文的分析，我们可以看到其实并没有什么神秘的力量和魔力融合在技术里面，而是业务的不断发展推动技术的不断发展，一步一个脚印，持续几年甚至10几年的发展，才能达到当前技术复杂度、先进性、牛逼度。抛开BAT各自差异很大的业务，站在技术的角度来看，其实BAT的技术架构基本是一样的，牛逼的公司技术都是这个范

2015-05-27 11:15:46 10274 5

原创 BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展

互联网技术发展之路（2）- 业务如何驱动技术发展在《互联网技术发展之路（1） - 技术发展的驱动力》一文中，我们详细阐述了对于服务类的业务来说，业务发展是技术发展的驱动力。那接下来我们就看看业务究竟是如何驱动技术发展的。互联网业务千差万别，但由于他们具有“规模决定一切”的相同点，其发展路径也基本上是一致的。互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成熟期。不同时期的差别主要体现

2015-04-14 10:08:11 8446 3

原创 BAT解密：互联网技术发展之路（1） - 技术发展的驱动力

互联网技术发展之路（1） - 技术发展的驱动力互联网行业是一个快速发展、快速变化的行业，新的业务、新的机会层出不穷，新的技术如雨后春笋般冒出，NoSQL、大数据、云、Node.js、Docker等，无时不刻都在轰炸程序员们的脑袋，难怪中国的程序员都流传一个说法：过了30岁不能做技术工作了，因为技术发展太快了！快节奏带来机会，但对于技术人员来说，更多的是带来挑战，甚至有时候是困惑。例如：1）Dock

2015-04-08 11:57:49 14523 17

原创 JDBC批量操作性能提升

JDBC当使用INSERT INTO....VALUES()语句批量插入的时候，应该使用JDBC的PreparedStatement的批量操作方法，而不是采用一条一条执行的方法。例如（来源：http://superjavason.iteye.com/blog/255423）：如上图，代码有3个关键的处理步骤：1）关闭自动提交2）addBatch3）executeBatch使用这种方法，SQLite

2015-03-31 11:17:41 3820

原创 java程序启动时cpu和负载高探索

这两天协助运维定位1个监控程序CPU占用率达到150%的问题，过程曲折，结论简单，很有意思：）首先我们来看一下cpu高时候截图：可以看到红色框中的监控程序CPU占用率都很高，但其实这些监控程序的实现很简单：发送1个http请求，收到响应后简单判断一下响应码，然后打印监控结果。这么简单的业务占用这么高的cpu，怎么感觉都不太可能，于是拿到监控程序的源码开始定位。

2015-02-12 18:58:46 11634 3

原创 CRC32算法冲突概率测试和分析

最近因为某个业务需要用到CRC32算法，但业务又不能容忍重复的数值出现，于是自然就想了解一下CRC32算法的冲突概率（或者叫碰撞概率）。本以为这种问题应该很多人分析过，结果找来找去就只看到一大堆数学公式，我这种数学盲完全看不懂。好不容易找到一张图，但看得云里雾里（原图链接：http://preshing.com/20110504/hash-collision-probabilities/ ）：既然

2015-01-16 11:34:28 22721 4

原创十年磨一剑之架构设计

浓缩10年工作经历精华，结合电信领域和互联网领域的经验，剥去架构设计高大上的神秘外衣，提炼架构设计的终极大法，菜鸟也能做架构设计，架构设计不过如此。主要内容包括：1）什么是架构设计2）架构设计的终极大法3）架构设计的基本原则4）如何提升架构设计能力详细请点击下载：十年磨一剑之架构设计

2014-12-24 10:12:14 6393 1

原创零缺陷开发技巧

零缺陷开发技巧，简单易懂，一学即会，一用就有效果，让你写10K代码只有1个bug的方法个人实践效果：10K代码1个bug, 个人负责的70%的版本0 bug详细请点击下载：零缺陷”开发技巧内容简介：1个原则：2/8原则2个技巧：防御性编程、代码写三遍3个条件：熟悉编程语言、单元测试、熟悉业务

2014-12-24 10:05:27 4155 2

转载专访李运华：程序员如何在技术上提升自己

原文链接： http://www.csdn.net/article/2014-10-20/2822190

2014-11-20 10:25:35 12918 17

原创 tcp 三次握手和四次断连深入分析：连接状态和socket API的关系

我敢打赌很少有人明白tcp状态和socket编程API之间的关系。不信？看看如下几个问题你是否知道吧：1）什么时候客户端才能够连接上server端，是server端调用bind后还是listen后还是accept后？2）什么情况下会出现FIN_WAIT_2状态。。。。。。。。。。。。。。。。。。。。。如果你不清楚的话，那么就听我细细道来

2014-10-28 10:59:22 6573

原创连载：面向对象葵花宝典：思想、技巧与实践（40） - DECORATOR模式

掌握了设计模式之道后，我们将以全新的方法来理解设计模式，这个方法更简单、更直观，不信？看几个样例就知道了=====================================================================【业务】假设你进入了一个信息安全管理非常严格的公司，这家公司不允许员工自行打印文档，所有的文档打印都需要交给文档打印系统统一管理。文档打印系统会记录每次打印的

2014-08-27 10:10:05 4796

原创连载：面向对象葵花宝典：思想、技巧与实践（39） - 设计原则 vs 设计模式

又是设计原则，又是设计模式，到底该用哪个呢？ =============================================================================在“设计模型”一章中，我们提到设计原则和设计模式是互补的，设计原则和设计模式互补体现在：设计原则主要用于指导“类的定义”的设计，而设计模式主要用于指导“类的行为”的设计。举一个很简单的例子：假设我们

2014-08-18 09:50:45 4664 1

原创连载：面向对象葵花宝典：思想、技巧与实践（38） - 设计模式之道

很多人能够熟练背诵出所有的设计模式，能够快速画出各种设计模式的UML类图，也能够熟练的写出《设计模式》一书中各个模式的样例代码。但一到实际的项目设计和开发的时候，往往都会陷入迷茫：要么无从下手，不知道哪个地方要用设计模式；要么生搬硬套，胡乱使用设计模式，将方案和代码搞得一团乱麻。============================================================

2014-07-31 13:56:43 5871 3

原创连载：面向对象葵花宝典：思想、技巧与实践（37） - 设计模式：瑞士军刀 or 锤子？

“设计模式”这个词几乎成为了软件设计的代名词，很多人非常天真的以为掌握了设计模式就掌握了软件设计，但实际上如果只是握了设计模式，软件设计的门都还没摸到！========================================================谈起设计模式，那是几乎无人不知，无人不晓，大名鼎鼎的“GOF”（中文有的翻译为“四人帮”）惊世之作，真是“平生不识GOF，学尽设计也枉然

2014-07-25 10:02:21 4571 2

原创连载：面向对象葵花宝典：思想、技巧与实践（36） - 设计原则如何用？

经过前面深入的阐述，SOLID的原则我们已经基本上讲清楚了，但如果想熟练的应用SOLID原则，仅仅知道SOLID是什么（what）还不够，我们还需要知道SOLID原则在什么时候和什么场景应用（when或where）。

2014-07-17 09:36:38 4041

原创连载：面向对象葵花宝典：思想、技巧与实践（35） - NOP原则

NOP，No Overdesign Priciple，不要过度设计原则。这应该是你第一次看到这个原则，而且你也不用上网查了，因为这个不是大师们创造的，而是我创造的：）之所以提出这个原则，是我自己吃过苦头，也在工作中见很多人吃过类似的苦头。你可能也见过这样的场景：产品提出了一个需求，设计师眼光非常长远，他甚至把5年后可能的业务变化都提出来并且加以设计了，让你不得不佩服设计师的高瞻远瞩的眼光，并

2014-06-29 09:52:53 4008 2

原创连载：面向对象葵花宝典：思想、技巧与实践（34） - DIP原则

DIP，dependency inversion principle，中文翻译为“依赖倒置原则”。 DIP是大名鼎鼎的Martin大师提出来的，他在1996 5月的C++ Reporter发表“ The Dependency Inversion Principle”的文章详细阐述了DIP原则，并且在他的经典著作《 Agile Software Development, Principles, Pa

2014-06-14 15:51:27 5111 2

原创连载：面向对象葵花宝典：思想、技巧与实践（33） - ISP原则

ISP，Interface Segregation Principle，中文翻译为“接口隔离原则”。和DIP原则一样，ISP原则也是大名鼎鼎的Martin大师提出来的，他在1996年的C++ Reporter发表“ The Interface Segregation Principle”的文章详细阐述了ISP原则，并且在他的经典著作《 Agile Software Development, Pri

2014-05-30 17:37:05 4094 7

原创连载：面向对象葵花宝典：思想、技巧与实践（32） - LSP原则

LSP，Liskov substitution principle，中文翻译为“里氏替换原则”。这是面向对象原则中唯一一个以人名命名的原则，虽然Liskov在中国的知名度没有UNIX的几位巨匠（Kenneth Thompson、Dennis Ritchie）、GOF四人帮那么响亮，但查一下资料，你会发现其实Liskov也是非常牛的：2008年图灵奖获得者，历史上第一个女性计算机博士学位获得者。其

2014-05-24 09:43:46 4344 4