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

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

《碟中谍》系列电影中，汤姆克鲁斯主演的亨特特工，无论什么情况，什么环境下都能够有惊无险的完成那些看似不可能的任务。对于技术人员来说，如果也能像汤姆克鲁斯那样，不管什么mission impossible最后都能解决，那迎娶白富美，当上CTO，走向人生巅峰都不是问题！“异地多活”看起来就是这样一个万能的大杀器，很多人理想中认为只要实现了“异地多活”，不管是新奥尔良水灾，美加大停电，蓝翔挖掘机。。。。。。等等都不再是问题。 不过，事实上，作为一个解决方案，异地多活是否最终有效，既取决于实施方如何去使用方案如何去设计（千万不要以为捡到倚天剑就是武林盟主），也取决于工具方案本身还有哪些不如意之处固有的约束和限制。要知道，即便是淘宝这样能够做到“异地多活”的公司而言，实际上也仍然有不够完美的地方。如果不意识到这些impossible mission，那么对于异地多活的理解就是错误的。Impossible Mission1 - “实时异地多活”异地多活本质上是通过异地的数据冗余，来保证在极端异常的情况下业务也能够正常提供给用户，因此数据同步是异地多活设计方案的核心。 通过网络将数据从A地同步到B地，会受限于一个普遍的物理规则，即：光速真空传播是每秒30万公里，在光纤中传输的速度大约是每秒20万公里，再加上传输中的各种网络设备的处理，实际还远远达不到光速的速度。除了距离上的限 ...继续阅读 (10)

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

不管是开发、测试、运维，每个技术人员心理多多少少都有一个成为技术大牛的梦，毕竟“梦想总是要有的，万一实现了呢”！正是对技术梦的追求，促使我们不断地努力和提升自己。然而“梦想是美好的，现实却是残酷的”，很多同学在实际工作后就会发现，梦想是成为大牛，但做的事情看起来跟大牛都不沾边，例如，程序员说“天天写业务代码还加班，如何才能成为技术大牛”，测试说“每天都有执行不完的测试用例”，运维说“扛机器接网线敲shell命令，这不是我想要的运维人生”。。。。。。知乎上类似的问题“天天写业务代码的程序员，怎么成为技术大牛，开始写技术代码？”关注人数有6K+，答案有120+，当时我也回答了并且点赞数最多，后来做职业等级晋升面评和沟通的时候，又有了新的发现和想法，于是有了系统的整理一篇文章的想法，希望让更多同学在技术大牛的路上能够少走很多弯路。由于我是程序员，所以以下的一些例子都是基于程序开发的，但大道理是相通的，测试、运维都可以借鉴。几个典型的误区拜大牛为师知乎上有人认为想成为技术大牛最简单直接、快速有效的方式是“拜团队技术大牛为师”，让他们平时给你开小灶，给你分配一些有难度的任务。我个人是反对这种方法的，主要的原因有几个：大牛很忙，不太可能单独给你开小灶，更不可能每天都给你开1个小时的小灶；而且一个团队里面，如果大牛平时经常给你开小灶，难免会引起其他团队成员的疑惑，我个人认为如果团队里的大牛如果真 ...继续阅读 (23)

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

“如何才能成为大牛”，这个问题很多人都问过我，我会写一个系列来回答“如何成为大牛”这个问题，这是第2篇。技术人的小目标首富王健林在采访时不经意的一句话“先定一个能达到的小目标，比方说我先挣它一个亿”瞬间刷爆了朋友圈，朋友们都在充分发挥调侃和自黑的潜力，各种段子都在说自己要先定一个能达到的小目标，比如说我先挣10 billion的津巴布韦元 ：）抛开首富的小目标对于我们普通老百姓来说过于宏大这点外，其实这句话也是挺有道理的，简单来说就是要循序渐进，不要期望一口吃成一个大胖子。这个道理其实平时大家也都懂，但在这个浮躁的社会，要真正理解并采取行动，并不那么简单，比如说“技术人员如何成为大牛”这个话题。我在拉勾网举行的“理想之上 广州站”进行了一次演讲：《吃的草够多，你也能成为大牛》，其中提到了10000小时理论，意思就是在一个专业方向上持续不断的积累10年，就可以成为业界大牛。这个简单的道理现场让很多朋友都觉得醍醐灌顶：原来成为大牛也不是那么难的事情，我也可以成为大牛！虽然理论上很简单，但真正要落地实行也并不那么容易，实行10000小时理论的关键在于坚持，我认为坚持的关键在于自己对于所从事的事业是否有“激情和兴趣”。这点当然是核心，但如果只靠激情支撑，持续10年也确实有挑战，正如一个朋友在分享会后问我的“要持续10年才能成为大牛啊，时间好长啊”！如果说做一件事要10年后才能修成正果，估计 ...继续阅读 (22)

“如何才能成为大牛”，这个问题很多人都问过我，我会写一个系列来回答“如何成为大牛”这个问题，这是第一篇，是拉勾理想之上广州站活动的现场演讲稿。===============================================================================================“8月6日，拉勾理想之上全国巡回广州站。阿里游戏资深架构师李运华，嘟嘟巴士联合创始人刘玉鑫，毒舌电影合伙人 董舒，机智云创始人兼总经理黄锡雄，阿里移动事业群UC市场部总经理周默，拉勾网CEO马德龙、音乐人周云蓬跟我们一起聊（唱）了聊（唱）他们心中的理想之上有哪些内容。”一碗有勺子的鸡汤大家好！我是来自阿里游戏的李运华。今天我的分享主题是《吃的草够多，你也能成为大牛》，这个标题一看就是一个类似于鸡汤文字，确实它是一碗鸡汤，但同时我也会把勺子给大家，所以你们除了能看到这碗鸡汤以外，也能喝到这碗鸡汤。大家看到我的第一印象是什么？（帅），年轻又帅？帅的话我算不上，年轻的话，我看起来是比较年轻的，我感觉比刚才马总（马德龙）那张照片还年轻，但是大家不要担心，我工作时间挺长的，大家可以怀疑我的年龄，不用担心我的实力。我工作已经将近12年了（其实12年才混到这个地步，天资实在是一般），在华为做了5年，在UC做了6年，现在主要负责阿里游戏的中间件和组件的架构设计和实现，包括 ...继续阅读 (11)

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

备注：本来想自己写一篇运维体系的文章的，但毕竟不是专业运维人员出身，担心讲的太肤浅，因此转载我的好朋友王金银（江湖人称老王）同学发表在InfoQ的运维体系介绍。老王的牛逼相信很多同学已经领教过了，全球运维技术大会深圳站一个人专场讲运维能讲3个小时，而且会场还爆满，更多老王的介绍可以参考文章的最后，也可以关注老王的微信公众号：互联网运维杂谈。原文链接：运维平台规划体系全介绍===================================================================================================================================运维平台规划体系全介绍识别运维平台的边界在哪儿，才能更好地构建平台，从而协助运维的日常工作。在之前的文章中，谈到过“运维的本质——可视化”，在可视化的篇幅中，着重介绍自动化的可视化和数据的可视化；在后续的篇章中又介绍了“互联网运维的价值体系”，里面分解了几个维度：质量、成本、效率、安全等。以上都是为了清楚地梳理运维的内容边界，基于这个边界，我们再考虑如何进行平台支撑。可以说前两篇文章都是为今天这篇文章作为铺垫，用理念先行，然后再考虑平台落地，最后再细化其中每个内容。我更习惯用如下的方式来整体表达运维的工作方法和思路。首先，价值导向。找到一个价值方向来牵引整个 ...继续阅读 (44)

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

1. 引言有幸参与了阿里游戏的一个高可用方案的设计，并且在网上发表了方案（面向业务的立体化高可用架构设计），后来参加GOPS全球运维大会深圳站，与众多行业高手交流，发现大家对“异地多活”这个方案设计非常感兴趣，毕竟“异地多活”的方案价值非常大，尤其是互联网行业，规模稍微大一点几乎都必须是标配；但同时大家都觉得“异地多活”的方案设计又很难，网络、数据、事务等各种问题混杂在一起，很多问题看似是无法解决的。比如说：“网络断了怎么保证数据一致性”、“怎么保证异地事务一致性”、“业务怎么无缝的在多个地点切换”。。。。。。等等。 其实大部分问题我们之前也遇到过，这些问题当时也困扰着我们，后来我们经过讨论和思考，发现其实很多时候我们困扰的主要原因是过于“追求完美的异地多活方案”，这样导致“异地多活”设计中出现很多了的思维误区，而如果不意识到这些思维误区，就会陷入死胡同，导致无法实现真正的“异地多活”方案。 接下来我将总结常见的思维误区，看看你踩中了哪个坑？ 2. 所有业务异地多活“异地多活”是为了保证业务的高可用，但很多朋友在考虑这个“业务”的时候，会不自觉的陷入一个思维误区：我要保证所有业务的“异地多活”！ 比如说假设我们需要做一个“用户子系统”，这个子系统负责“注册”、“登录”、“用户信息”三个业务。为了支持海量用户，我们设计了一个 ...继续阅读 (57)

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

【文武双全】前面讲了那么多，看起来都是和项目管理相关的的，例如“有的放矢”是关于找目标的、“合纵连横”是关于沟通协调的、“运筹帷幄”是关于项目规划的。。。。。。架构师怎么变成了项目经理了，说好的技术呢？ 真正的架构师，当然必须具备一定的项目经理技能，但更重要的还是技术能力，道理很简单：再好的饼，最后实现不了，都是扯淡！我将“项目管理能力”称之为“文”的能力，“技术能力”称之为“武”的能力，架构师必须文武双全，才能最终把事情搞定！ 架构师的“武”体现在很多方面，既有微观层面的，例如如何设计一个高性能的并发框架（可以参考Disruptor，大量的技术细节，例如CPU cache，cache line，false sharing等）；也有宏观层面的，例如采用HBase还是用MySQL存储；还有和业务相关的，例如某个功能应该如何设计才能具备可扩展性。业务层面的相关的技术问题，如果没有相关的业务背景，讲起来比较费劲，也不好理解，这里就不展开了。我们讲讲这些重构项目中和业务无关的一些技术。 我被问到的最多的问题其实也是宏观层面的。其中一个主要的问题是“这些系统的业务都不一样，你之前也没有类似业务背景，你怎么识别出M系统重构的目标是数据解耦，S系统重构的目标是高可用呢，X系统重构的目标是系统解耦呢？” 秘密就在架构设计和重构其 ...继续阅读 (70)

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

【运筹帷幄】一般来说，需要架构重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。 可以想象一下，假如我们拿到一个架构问题列表，其中有50个问题，那我们应该怎么去把这50个问题最终解决呢？最简单的做法是每次从中挑一个解决，最终总会把所有的问题都解决。这种做法操作起来比较简单，但效果会很差，为什么呢？第一个原因是没有区分问题优先级，所有问题都一视同仁，没有集中有限资源去解决最重要或者最关键的问题，导致最后可能出现做了大半年，回头一看好像做了很多事情，但没取得什么阶段性的成果。第二个原因是没有将问题分类，导致相似问题没有统筹考虑，方案可能出现反复，效率不高。第三个原因是会迫于业务版本的压力，专门挑容易做的实施，到了稍微难一点的问题的时候，就因为复杂度和投入等原因被搁置，达不到真正重构的真正目的。 以X系统为例，在我加入前，其实也整理了系统目前存在的问题，大的项包括：可用性、性能、安全、用户体验等，每个大项又包括十几二十个子项。但是实施的时候基本上就是挑软柿子捏，觉得哪个好落地、占用资源不太多，就挑来做，结果做了半年，好像做了很多功能 ...继续阅读 (19)

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

【合纵连横】【合纵】架构重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免的会影响业务功能的开发。因此，要想真正推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通。注意这里我不是指要谈办公室政治，而是指要和利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和争执。 道理很简单，但如何做才是关键！一般的技术同学谈到架构重构的时候，就会搬出一大堆技术术语：可扩展性、可靠性、性能、耦合、代码很乱。。。。。。但以我的实际经验来看，如果和非技术同学这样沟通，效果如同鸡同鸭讲，没有技术背景的同学很难理解，甚至有可能担心我们是在忽悠TA。例如：技术同学说：我们系统现在的可扩展性太差了，改都改不动！产品同学想：咦，可扩展性，和扩胸运动有关么？。。。。。扩展什么呢，怎么会改不动呢，不就是找个地方写代码嘛。。。。。。技术同学说：我们的可靠性太差，现在才3个9，业界都是4个9！项目经理想：啥是3个9，三九感冒灵？。。。。。。4个9和3个9不就是差个9嘛，和可靠有什么关系。。。。。。技术同学说：我们系统设计不合理，A业务和B业务耦合！运营同学想：咦，耦合，莲藕还是藕断丝连？。。。。。。A业务和B业务本来就是互相依赖的呀。。。。。。耦合为什么不合理呢？。。。。。以上的样例并无嘲笑产品运营和项目同学不懂技术的意思，而是说明有的技术术 ...继续阅读 (26)

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

序言对一个程序员来说，世界上最痛苦的事情是什么呢？有的人会说：编码的时候产品改需求！有的人会说：看别人不知所云的代码！有的人会说：定位一个百年不遇千年难寻的线上不定时偶尔出现的bug！有的人会说：找不到女（男）朋友！。。。。。。。。。。。。。。。。。。。。。。。。。。但我要说，这些痛苦其实都不算什么，要么是多花点时间去解决（比如说改需求、看代码），要么是多花点心思（比如说找另一半、定位疑难bug），而我接下来说的这个事情才是最痛苦的，既要说得动老板，也要镇得住同行；既要技术攻关，又要协调资源；既要保证业务正常发展，又要在指定时间内完成目标。。。。。。总之就是十八般武艺要样样精通。 这个事情就是“架构重构”，比“架构重构”还要痛苦的就是“边做业务边架构重构”！我们的产品形象的形容为“给飞驰的法拉利跑车换引擎”，为何这样说呢？首先：业务不能停，不能为了架构重构而终止业务的开发，将法拉利停下来换引擎，别人都跑远了；其次：业务不能出问题，不能因为架构重构导致业务无法运行，法拉利修出问题跑不了，别人也跑远了；第三：要根本解决问题，而不是修修补补，不是给法拉利引擎加点油，清洁一下就可以了，而是要换上新的引擎。 巧合的是，我加入UC后到现在已经做了3个系统的架构重构了（戏称“救火队长”），而且每个系统的特点都不一样，过程中各种各样的问题都遇到过，坑也踩过，也积累了一些经验。接 ...继续阅读 (15)

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

互联网的业务千差万别，不同的业务分解下来有不同的系统，所以业务层没有办法提炼一些公共的系统或者组件，但抛开业务的差异，各个互联网业务发展最终面临的问题都是类似的：就是复杂度越来越高，也就是说，业务层面对的主要技术挑战是“复杂性”。幸运的是，面对业务层的技术挑战，我们有一把屠龙宝刀，神挡杀神，佛挡杀佛，不管什么业务难题，用上屠龙宝刀一试都迎刃而解。这把屠龙宝刀就是“拆”。复杂性的一个主要原因就是系统越来越庞大，业务越来越多，降低复杂性最好的方式就是“拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里面去。以一个简单的电商系统为例：如上图，我们这个模拟的电商系统经历了3个发展阶段：第一阶段：所有功能都在1个系统里面第二阶段：将商品和订单拆分到2个子系统里面第三阶段：商品子系统和订单子系统分别拆分成了更小的3个子系统以上只是样例，实际上随着业务的发展，子系统会越来越多，据说淘宝内部大大小小的已经有成百上千的子系统了。虽然说“拆”是屠龙宝刀，但也不能乱拆，拆到合适的粒度是一门艺术，拆的太粗复杂度没有降低，但也不是意味着拆的越细越好，主要原因如下：1）子系统太多，运维成本会增加，包括系统资源增加、问题定位复杂度增加2）子系统太多，开发成本可能会增加，例如做一个需求可能要10几个系统配合3）子系统太多，子系统的交互又会越来越复杂，单个系统的复杂度降低，但整体的复杂度还是会升高。 ...继续阅读 (24)

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

软件开发领域有一个流行的原则：DRY，Don’t repeat yourself，我们翻译过来更形象通俗：不要重复造轮子。开源项目主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目，可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？ 然而现实往往没有那么美好，开源项目虽然节省了大量的人力和时间，但带来的问题也不少，相信绝大部分同学都踩过开源软件的坑，小的影响可能是宕机半小时，大的问题可能是丢失几十万数据，甚至灾难性的事故是全部数据都丢失。 除此以外，虽然DRY原则摆在那里，但实际上开源项目反而是最不遵守DRY原则的，重复的轮子好多，尤其是歪果仁，一看哪个开源方案不爽，自己就吭哧吭哧搞一个差不多的：你有MySQL，我有PostgreSQL；你有MongoDB，我有Cassandra；你有memcached，我有redis；你有Gson，我有Jackson；你有Angular，我有React。。。。。。总之放眼望去，其实相似的轮子很多！相似轮子太多，选择就是让人头疼的问题了。 怎么办？完全不用开源项目几乎是不可能的，我们需要更加聪明的去选择和使用开源项目。形象点说：不要重复发明轮子，但要找到合适的轮子！你开的是保时捷，可别找个拖拉机的轮子。 接下来我 ...继续阅读 (9)

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

互联网业务用户层技术主要包括：用户管理、消息推送、存储云、图片云。用户管理互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来，因此用户管理是互联网业务必不可少的一部分。稍微大一点的互联网业务，肯定会涉及到多个子系统，这些子系统不可能每个都自己来管理这么庞大的用户，由此引申出用户管理的第一个目标：SSO，单点登录，又叫统一登录。单点登录的技术实现手段较多，例如cookie、token等，最有名的开源方案当属CAS。除此之外，当业务做大成为了平台后，开放成为了促进业务进一步发展的手段，必须允许第三方应用接入，由此引申出用户管理的第二个目标：授权登录。现在最流行的授权登录就是OAuth2.0协议，这个基本上已经成为了事实上的标准，如果要做开放平台的话，最好用这个协议，私有协议漏洞多，第三方接入也麻烦。用户管理面临的主要问题是用户数巨大，一般至少千万级，QQ、微信、支付宝这种巨无霸应用，都是亿级用户，不过一般也不要被这个数据给吓倒了，用户管理虽然数据量巨大，但实现起来并不难，原因是什么呢？ 因为用户数据量虽然大，但是不同用户之间没有关联，A用户登录，和B用户登录基本没有关系。因此虽然数据量巨大，但我们用一个简单的拆分手段就能轻松应对。综合一下，用户管理关键的技术如下：消息推送消息推送根据不同的途径，分为短信、邮件、站内信、APP推送，除了APP外，不同的途径基本上是调用不同的A ...继续阅读 (53)

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

原文链接：http://www.csdn.net/article/2015-10-27/2826042========================================================面向业务的立体化高可用架构设计发表于2015-10-27 10:47| 2924次阅读| 来源《程序员》杂志| 8 条评论| 作者李运华《程序员》杂志2015年10月B架构李运华面向对象摘要：为了实现阿里九游游戏接入系统的业务高可用，技术人员跳出传统的面向系统的高可用的思路，转而从业务的角度来整体考虑高可用，最终实现了一套立体化的高可用架构，本文逐一展示这套立体化高可用架构的一些具体实践。通常情况下我们在谈论高可用架构设计的时候，主要关注的是系统结构的高可用，例如主备架构、集群架构、多中心架构。我们做架构设计的时候，也主要是从系统结构本身出发，例如我们把单机改为双机、双机改为集群、单机房改为异地多机房等等。这种以系统结构为目标的高可用架构设计，更多的是从技术角度出发，但其实我们都知道，无论技术多先进，架构多强大，都不可能保证100%不出问题的。蓝翔的挖掘机一铲子下去，支付宝就要故障2小时；程序员的误操作，携程12小时不能提供业务；某个黑客1000台肉鸡攻过来，网站可能就拒绝服务了......因此，真正做到高可用，不能单纯从系统结构的角度出发来 ...继续阅读 (38)

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

上一篇博文《BAT解密：互联网技术发展之路（6）- 服务层技术剖析》中，介绍了互联网业务发展特点的中的“复杂性”的应对方式，本文介绍互联网业务发展特点的另外两个方面“高性能”、“高可用”。一般人提到高性能时第一想到的就是优化，提到高可用时第一反应就是双机或者备份，但是对于互联网这种超大容量和访问量的业务来说，这两个手段都是雕虫小技，无法应对互联网业务的高性能和高可用需求，互联网业务的高可用和高性能，需要从更高的角度去设计，这个高点就是“网络”，所以我将这些措施统一划归为“网络层”。注意这里的网络层和大家通常理解的如何搭建一个局域网这种概念不一样，强调的是站在网络层的整体设计，而不是某个具体网络的搭建。负载均衡故名思议，负载均衡就是将请求均衡的分配到多个系统上。使用负载均衡的原因也很简单：每个系统的处理能力是有限的，为了应对大容量的访问，必须使用多个系统。例如一台32核64G内存的机器，每秒处理http请求最多不会超过10万，而互联网的业务，不到百万级都不好意思说自己是互联网业务。负载均衡虽然理解起来简单，但实现方式就很多了，可大可小；可以软件实现，也可以硬件实现，由于涉及的技术很多，这里只是简单的介绍常用技术。【DNS】DNS是最简单的、也是最常见的负载均衡方式，一般用来实现地理级别的均衡，例如北方的用户访问北京的机房，南方的用户访问广州的机房；一般不太会使用DNS来做机器级别的负 ...继续阅读 (35)