来自：码农翻身（微信号：coderising）作者：IBM刘欣我是一个线程，我一出生就被编了个号： 0x3704，然后被领到一个昏暗的屋子里， 这里我发现了很多和我一模一样的同伴。我身边的同伴0x6900待的时间比较长， 他带着沧桑的口气对我说：“我们线程的宿命就是处理包裹。把包裹处理完以后还得马上回到这里，否则可能永远回不来了。”我一脸懵懂，包裹，什么包裹？“不要着急，马上你就会明白了， 我们这里是不养闲人的。”果然，没多久，屋子的门开了， 一个面貌凶恶的家伙吼道：“0x3704 ,出来！”我一出来就被塞了一个沉甸甸的包裹，上面还有附带着一个写满了操作步骤的纸。“快去，把这个包裹处理了。”“去哪儿处理？”“跟着指示走， 先到就绪车间”果然，地上有指示箭头，跟着它来到了一间明亮的大屋子，这里已经有不少线程了， 大家都很紧张，好像时刻准备着往前冲。我刚一进来，就听见广播说：“0x3704，进入车间”我赶紧往前走， 身后很多人议论说：”他太幸运了， 刚进入就绪状态就能运行”“是不是有关系？”“不是，你看人家的优先级多高啊， 唉~”前边就是车间， 这里 ...继续阅读 (3)

技术在过去的几十年里进步很快，也将在未来的几十年里发展得更快。今天技术的门槛下降得越来越快，原本需要一个团队做出来的Web应用，现在只需要一两个人就可以了。同时，由于公司组织结构的变迁，也决定了赋予每个人的职责将会越来越多。尽管我们看到工厂化生产带来的优势，但是我们也看到了精益思想带来的变革。正是这种变革让越来越多的专家走向全栈，让组织内部有更好的交流。你还将看到专家和全栈的两种不同的学习模式，以及全栈工程师的未来。技术的革新史从开始的CGI到MVC模式，再到前后端分离的架构模式，都在不断地降低技术的门槛。而这些门槛的降低，已经足以让一两个人来完成大部分的工作了。CGI二十年前的网站以静态的形式出现，这样的网站并不需要太多的人去维护、管理。接着，人们发明了CGI(通用网关接口，英语：Common Gateway Interface)来实现动态的网站。下图是一个早期网站的架构图：当时这种网站的URL类似于： https://www.phodal.com/cgi-bin/getblog(PS：这个链接是为了讲解而存在的，并没有真实存在。)用户访问上面的网页的时候就会访问，cgi-bin的路径下对应的getblog脚本。你可以用Shell返回这个网页：#!/bin/shecho Content-type: text/plainecho hello,worldBlabla，各种代码混乱地夹 ...继续阅读 (8)

文/雷子，来源/公众号：东京 IT 人号外！号外！走过，路过，不要错过！日本 IT 业的狗血八卦继续独家放送啦！！2015 年 9 月 3 日，随着东京最高法院驳回瑞穗证券的上诉，维持二审的原判结果，一个长达 10 年的诉讼终于画下了句号。这个判例将对 IT 行业产生深远的影响：如果程序的 bug 导致了巨大的经济损失，应该由谁来承担？用户？运营商？还是系统开发商？bug：计算机程序里的错误今天故事的主角是，瑞穗(みずほ)证券，东京证券交易所(下文简称东证)，和富士通。各位富士通的同学，雷子真的不是富士通黑啊。你们公司行业内第一，项目多，所以卦点就多啊！要是又一次伤害了你们的感情，看下图能原谅我不……嗯，该说的也都说过了，下面正式开始。（一）瑞穗证券的乌龙指事件如果时光能够倒流，让瑞穗证券的交易员田中君(化名)穿越回 2005 年 12 月 8 日东证开盘前的那几分钟，田中君会不会选择把自己那根乌龙指给掰断呢？乌龙指(fat finger)：是指股票交易员、操盘手、股民在交易的时候，不小心敲错了价格、数量、买卖方向等。正是由于田中君的一次错误输入，让他所在的瑞穗证券遭受了超过 400 亿日元的天价损失。虽然日元那面额画得跟冥币似的，400 亿日元也还是相当值些银子滴(按照当时的汇率，约为人民币 27 亿元)。这天，是日本公司 J-Com 首次公开上市(I ...继续阅读 (6)

来自上海游族网络的运维总监李志勇，在3月4日云栖社区中带来的分享“如何运维千台以上游戏云服务器”。本次分享重点是云时代的运维，包括游戏上云部署整体方案、游戏服务器批量运维管理，并对企业选择RDS还是自建MySQL数据库给出了自己建议。游戏产品架构进化史图一：游戏产品架构进化史经过近七年的高速发展，公司游戏服务器从100台增长到10000+台，游族整体游戏架构也经过了三个阶段的演变：公司早期广泛使用的第一代架构，当时主流的产品都是以DB+计算+前端这样的3个角色开发设计并部署，服务器以物理机为主，一个游戏区组需要2~4台服务器，不同的机器承担不同的角色。这种架构方案效率低，基本上不可能实现一天开100个区组（100个区组大概需要400台服务器）；随着业务量的增长和虚拟化技术广泛使用，游族整体游戏架构更新为第二代架构，全面采用虚拟化技术，把一台高配的物理机器虚拟化成多台符合游戏需求的虚拟机来使用，并实现了ALL IN ONE的系统架构。该架构方案运维效率高，适合规模开展游戏运营，但不具备业务高可用特性，一天开100个区组成为常态；为了迎合大区大服、全球同服，游族融合了前两代架构的特点，推出了第三代架构，按角色分拆并形成服务集群模式。集群架构结合了物理机与虚拟化的优势，实现弹性扩容，游戏逻辑以服务进程或集群配置项的形式提供服务。该架构方案运维效率更高，可实现秒级开 ...继续阅读 (42)

架构漫谈是由资深架构师王概凯Kevin执笔的系列专栏，专栏将会以Kevin的架构经验为基础，逐步讨论什么是架构、怎样做好架构、软件架构如何落地、如何写好程序等问题。专栏的目的是希望能抛出一些观点，并引发大家思考，如果你有感触或者新的感悟，欢迎联系专栏负责人Gary（微信greenguolei）深聊。本文是漫谈架构专栏的第一篇，作者将会通过类比的方式来介绍什么是架构以及为什么会产生架构。缘起一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义，请教过很多人，结果发现，没有大家都认可的定义。套用一句关于big data流行的笑话，放在架构上也适用：Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。事实上，架构在软件发明时的N多年以前，就已经存在了，这个词最早是跟随着建筑出现的。所以，我觉得有必要从源头开始，把架构这个概念先讨论清楚，只有这样，软件行业架构的讨论才有意义。什么是架构？架构的英文是Architecture，在Wikipedia上，架构是这样定义的：Architecture (Latin architectura, from ...继续阅读 (12)

目前讨论架构实操（术）的文章较多，讨论架构理念（道）的较少，本文基于作者在大型电商系统架构方面的一些实践和思考，和大家聊聊架构理念性的东西，希望能够抛砖引玉，推进大家对架构的认识。什么是道，什么是术？道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大路通罗马，罗马是道，大路是术。道为本，术为途，如果事先知道罗马在哪里，那么遍地是路，路路相通。架构也是如此，如果能领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型 、架构境界等。架构的本质任何系统，自然情况下，都是从有序到无序，这是有科学依据的， 按照热力学第二定律，自然界的一切自发过程都有方向性，一个孤立系统会由有序变为无序，即它的熵会不断增加，最终寂灭。但生物可以通过和外界交互，主动进行新陈代谢，制造 “负熵” 来保证自身有序，继续生存。同样，一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。架构的本质就是对系统进行有序化重构，不断减少系统的 “熵”，使系统不断进化。那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。分的 ...继续阅读 (11)

一. 引言在如今这个互联网时代， 有一家公司家喻户晓——它自 1998 年问世以来， 在极短的时间内就声誉鹊起， 不仅超越了所有竞争对手， 而且彻底改观了整个互联网的生态。 这家公司就是当今互联网上的第一搜索引擎： 谷歌 (Google)。在这样一家显赫的公司背后， 自然有许许多多商战故事， 也有许许多多成功因素。 但与普通商战故事不同的是， 在谷歌的成功背后起着最关键作用的却是一个数学因素。本文要谈的就是这个数学因素。谷歌作为一个搜索引擎， 它的核心功能顾名思义， 就是网页搜索。 说到搜索， 我们都不陌生， 因为那是凡地球人都会的技能。 我们在字典里查个生字， 在图书馆里找本图书， 甚至在商店里寻一种商品， 等等， 都是搜索。 只要稍稍推究一下， 我们就会发现那些搜索之所以可能， 并且人人都会， 在很大程度上得益于以下三条：搜索对象的数量较小——比如一本字典收录的字通常只有一两万个， 一家图书馆收录的不重复图书通常不超过几十万种， 一家商店的商品通常不超过几万种， 等等。搜索对象具有良好的分类或排序——比如字典里的字按拼音排序， 图书馆里的图书按主题分类， 商店里的商品按品种或用途分类， 等等。搜索结果的重复度较低——比如字典里的同音字通常不超过几十个， 图书馆里的同名图书和商店里的同 ...继续阅读 (4)

背景说到底，Medium是个社交网络，人们可以在这里分享有意思的故事和想法。据统计，目前累积的用户阅读时间已经超过14亿分钟，合两千六百年。我们支持着每个月两千五百万的读者以及每周数以万计的文章发布。我们不想Medium的文章以阅读量为成功的依据，而是观点取胜。在Medium，文章的观点比作者的名头更重要。在这里，对话促进想法，并且很看重文字的力量。我是Medium开发团队的负责人，此前在Google工作，负责开发Google+和Gmail，还创立了Closure项目。业余时间我喜欢滑雪跳伞和丛林冒险。团队介绍说起团队我非常自豪，这是一群富有好奇心而且想法丰富的天才，大家凑到一块是想做大事的。团队以跨功能的任务驱动，这样每个人既可以专攻，又可以毫无压力的对整个架构有所贡献。我们的理念就是接触的方面越多，对团队的锻炼越大。更多关于团队的理念见此。在工作组织方面，我们有着很大的自由度，当然作为一个公司组成，我们还是有季度目标的，并且鼓励敏捷开发模式。我们使用GitHub进行code review和问题跟踪，用Google Apps作为邮件、文档和表单系统。跟很多团队习惯使用Trello不同，我们是Slack和slack机器人的重度用户。原始架构最开始的时候，Medium部署在EC2上，用Node.js实现，后来公测的时候迁移到了DynamoDB。其中有个节点用来处理图片，负责将复杂的处 ...继续阅读 (19)

原文：Understanding Progressive Enhancement作者：Aaron Gustafson译者：空帷 @ Taobao UED自 1994 年开始，Web 开发社群就擂起了名为“平稳退化 (Graceful Degradation)”的大鼓。这是一个从工程界引入的概念，其主旨是为那些最新最好的浏览器提供更全方位的浏览体验，而对不幸使用 Netscape 4 的人们仅提供很少的一些基本功能。这个方法的确能够奏效，但它却并不真正符合 Tim Berners-Lee （译注：万维网之父）对“普及的可访问型 Web (Universally Accessible Web)”的设计初衷。大约十年之后，一些聪明的人开始对“平稳退化”产生质疑，并最终发现它在许多层面上都存在着缺陷。他们致力于改善内容可利用性 (Content Availability)、全局可访问性 (Overall Accessibility) 和移动设备浏览器的能力，并为 Web 开发寻觅到一条新的途径 —— 一条聚焦于内容并能为旧设备提供更多实际支持的途径。在 2003 年度的 SXSW （译注：西南偏南节庆及会议，South by Southwest Festivals ...继续阅读 (9)

一直都听说DOM很慢，要尽量少的去操作DOM，于是就想进一步去探究下为什么大家都会这样说，在网上学习了一些资料，这边整理出来。首先，DOM对象本身也是一个js对象，所以严格来说，并不是操作这个对象慢，而是说操作了这个对象后，会触发一些浏览器行为，比如布局（layout）和绘制（paint）。下面主要先介绍下这些浏览器行为，阐述一个页面是怎么最终被呈现出来的，另外还会从代码的角度，来说明一些不好的实践以及一些优化方案。浏览器是如何呈现一张页面的一个浏览器有许多模块，其中负责呈现页面的是渲染引擎模块，比较熟悉的有WebKit和Gecko等，这里也只会涉及这个模块的内容。先用文字大致阐述下这个过程：解析HTML，并生成一棵DOM tree解析各种样式并结合DOM tree生成一棵Render tree对Render tree的各个节点计算布局信息，比如box的位置与尺寸根据Render tree并利用浏览器的UI层进行绘制其中DOM tree和Render tree上的节点并非一一对应，比如一个"display:none"的节点就只会存在于DOM tree上，而不会出现在Render tree上，因为这个节点不需要被绘制。上图是Webkit的基本流程，在术语上和Gecko可能会有不同，这里贴上Gecko的流程图，不过文章下面的内容都会统一使用Webkit的术语。影响页面呈现的因素有许多， ...继续阅读 (8)

程序员看到全栈这个概念，大概会有两种反应：1. 卧槽，这个好，碉堡了2. 你懂毛，全栈就是样样稀松以上两种反应其实都有失偏颇，即使只做一种技术，做的很菜的多的是，而全栈但是样样都做的不错的也不少，更别说这个世界还存在另外一种爆栈型的程序员，做什么什么精。全栈学徒至少要掌握以下几种技能：Web 前端开发，至少掌握一种前端框架Server 后端开发，至少掌握一种后端框架Server 运维，掌握 Linux Server 的搭建与维护客户端开发，iOS 和 Android 至少掌握一种数据库，掌握 SQL 和 NoSQL 数据库而获得“全栈”这个称谓则应该至少独当一面的一个人完成一款产品的构建，并且真的经历过商业化运作，被自己的“愚蠢”坑过无数次。由此可见，全栈的门槛还是挺高的，并不是说掌握以上五种技能，就能称为全栈，至少要加个学徒来修饰一下，也正是因为太多学徒自诩全栈，才导致第二种反应如此广泛。不过，这篇文章的题目是 —— 为什么你应该尝试全栈，所以讨论点并不在要不要做全栈，而是尝试。外行与内行过去几年里，我和不少团队的人聊过，发现绝大部分的团队矛盾都在于——Server 端的不懂客户端，设计出来个 API 后瞎 BB设计师不懂客户端，设计个交互瞎 BB客户端不懂 Server，对着 API ...继续阅读 (8)

英文原文：The Only Technique To Learn Something New有人曾从我工作的一家公司盗取了9千万美元。我不太懂得如何观人识人。这家公司最终关门了。有一些事情我就是学不会。我很容易相信一个人。因此，无论我如何尝试，判断一个人对我来说，简直太难了。所以，我寻找擅长做这件事的人，我让他们给我提供帮助。不要强迫自己学习那些你不想或者不属于你天赋所及的事情。天赋的作用到底有多大？非常小。但你需要从它开始起步。天赋是技能的种子。你如何得知你在某个方面具有天赋？当你10岁时，如果你热爱它，如果你梦到过它，如果你喜欢阅读这方面的内容。请继续阅读以下内容，你会发现你的天赋到底在哪里。当我说：每一个人在许多方面都具有天赋。请相信我。在过去的20多年里，我一直在试着学习一些东西，而且我希望把它们学好。写作、编程、商业技巧（领导力，销售，协商和决策制定等等），戏剧，游戏。所以，我专门研究出了一项由10个步骤组成的学习方法。1、热爱你学习的东西如果你不能从“热爱”出发，那么那些热爱它们的人将会战胜那些仅仅“喜欢”或者“讨厌”它们的人。这是一条放之四海而皆准的规则。第一个从西伯利亚出发直至阿拉斯加穿越北极的人，即使零下60多度，他依旧热爱他所做的事情。其他人可能宁愿呆在东非的大草原上。在我第一次写下&ldq ...继续阅读 (11)

相关文章：关于烂代码的那些事（上）关于烂代码的那些事（中）假设你已经读过烂代码系列的前两篇：了解了什么是烂代码，什么是好代码，但是还是不可避免的接触到了烂代码（就像之前说的，几乎没有程序员可以完全避免写出烂代码！）接下来的问题便是：如何应对这些身边的烂代码。1. 改善可维护性改善代码质量是项大工程，要开始这项工程，从可维护性入手往往是一个好的开始，但也仅仅只是开始而已。1.1. 重构的悖论很多人把重构当做一种一次性运动，代码实在是烂的没法改了，或者没什么新的需求了，就召集一帮人专门拿出来一段时间做重构。这在传统企业开发中多少能生效，但是对于互联网开发来说却很难适应，原因有两个：互联网开发讲究快速迭代，如果要做大型重构，往往需要暂停需求开发，这个基本上很难实现。对于没有什么新需求的项目，往往意味着项目本身已经过了发展期，即使做了重构也带来不了什么收益。这就形成了一个悖论：一方面那些变更频繁的系统更需要重构；另一方面重构又会耽误开发进度，影响变更效率。面对这种矛盾，一种方式是放弃重构，让代码质量自然下降，直到工程的生命周期结束，选择放弃或者重来。在某些场景下这种方式确实是有效的，但是我并不喜欢：比起让工程师不得不把每天的精力都浪费在毫无意义的事情上，为什么不做些更有意义的事呢？1.2. 重构step by step1.2.1. 开始之前开始改善代码的第一步是把IDE的重构快捷键设到一个 ...继续阅读 (7)

今天的分享主要来自我之前的工作经验以及平时的学习总结和思考。我之前的背景主要是做框架、系统和平台架构，之前工作过的公司 eBay、携程、唯品会都是平台型互联网公司，所以今天主要带着平台架构视角和大家分享心得体会。架构的视角每个人都不一样，可以说一万种眼光，有业务架构、安全架构、平台架构、数据架构，各不相同，这里仅是我的一家之言，欢迎大家加入『聊聊架构』社群参与讨论。今天聊的话题主要包括以下几点：我对架构定义的理解架构的迭代和演化性构建闭环反馈架构（Architecting for closed loop feedback）谈谈微服务架构和最新主题架构和组织文化关系架构师心态和软技能我对一些架构师争议主题的看法我对架构定义的理解大概在7~8年前，我曾经有一个美国对口的架构师 mentor，他对我讲架构其实是发现利益相关者（stakeholder），然后解决他们的关注点（concerns），后来我读到一本书《软件系统架构：使用视点和视角与利益相关者合作》，里面提到的理念也是这样说：系统架构的目标是解决利益相关者的关注点。这是从那本书里头的一张截图，我之前公司分享架构定义常常用这张图，架构是这样定义的：每个系统都有一个架构架构由架构元素以及相互之间的关系构成系统是为了满足利益相关者（stakeholder）的需求构建的利益相关者都有自己的关注点（concerns）架构由架构文档描述架构文 ...继续阅读 (27)

背景之前做日志收集模块时，用到flume。另外也有的方案，集成kafaka来提升系统可扩展性，其中涉及到消息队列当时自己并不清楚为什么要使用消息队列。而在我自己提出的原始日志采集方案中不适用消息队列时，有几个基本问题：1. 日志文件上传过程，有个基本的生产者-消费者问题；2. 另外系统崩溃时，数据丢失的处理问题。今天，几位同事再次谈到消息队列这么个东西，很NB的样子，我也想弄清楚，OK，搞起。什么是消息队列消息队列（Message Queue，简称MQ），从字面意思上看，本质是个队列，FIFO先入先出，只不过队列中存放的内容是message而已。其主要用途：不同进程Process/线程Thread之间通信。为什么会产生消息队列？这个问题问的好，我大概查了一下，没有查到最初产生消息队列的背景，但我猜测可能几个原因：不同进程（process）之间传递消息时，两个进程之间耦合程度过高，改动一个进程，引发必须修改另一个进程，为了隔离这两个进程，在两进程间抽离出一层（一个模块），所有两进程之间传递的消息，都必须通过消息队列来传递，单独修改某一个进程，不会影响另一个；不同进程（process）之间传递消息时，为了实现标准化，将消息的格式规范化了，并且，某一个进程接受的消息太多，一下子无法处理完，并且也有先后顺序，必须对收到的消息进行排队，因此诞生了事实上的消息队列；不管到底是什么原因催生了消息 ...继续阅读 (19)

英文原文：Write Code Every Day去年秋天，我的个人项目似乎走到了尽头：我一直没能取得必要的进展，在不牺牲我的主业（可汗学院的全职工作） 的情况下，我无法完成更多的个人编程事项。我个人项目上的工作始终存在着几个严重问题。我把这些工作主要放在周末，但有时也可能是周末的晚上。事实上，这种安排根本不合适。想要完成如此众多的工作（如果没有完成的话，我会产生挫折感），仅仅利用周末时间，对我来说压力太大，我有点儿吃不消。而且，这个问题本身就充满了矛盾 - 我既无法保证每个周末的空闲时间，也不想把整个周末都用在编程上（失去放松或者做点其他有趣事情的机会）。另外一个问题是，间隔一周对于同一段代码上的工作来说，时间太长了。很容易忘记自己究竟做过些什么（即使记笔记，帮助也不大）。如果碰巧错过一个周末，将导致两个星期的缺口。实际上，这种基于多个星期的工作环境切换非常致命（因为缺乏必要的关注，我的很多个人项目已经无疾而终）。去年，Jennifer Dewalt为了自学编程，在一百八十天内设计编写了一百八十个 Web 应用程序和网站。我深受启发和鼓励，觉得自己很有必要尝试一下类似的策略：每天都为自己的个人项目做一点工作，而不是集中在每个周末。我决定给自己定下几条规则：每天编写代码。我可以撰写文档、博客、或者做任何其他事情，但必须在写完代码之后。代码必须可用。无需调整缩进，无需重新格式化，尽可 ...继续阅读 (25)

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口（类似 iPhone 的 app）。几乎没有性能开销，可以很容易地在机器和数据中心中运行。最重要的是，他们不依赖于任何语言、框架包括系统。起源Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，源代码托管在 Github 上，基于go语言并遵从 Apache2.0 协议开源。Docker 自2013年以来非常火热，无论是从 github 上的代码活跃度，还是 Redhat 在 RHEL 6.5 中集成对 Docker 的支持，就连 Google 的 Compute Engine 也支持 docker 在其之上运行。一款开源软件能否在商业上成功，很大程度上依赖三件事：1）成功的user case，2）活跃的社区，3）一个好故事。 dotCloud 自家的 PaaS 产品建立在 docker 之上，长期维护且有大量的用户，社区也十分活跃，接下来我们看看 docker 的故事。环境管理复杂：从各种OS到各种中间件到各种App，一 ...继续阅读 (20)

Docker自从诞生以来就一直备受追捧，学习Docker是一件很炫酷、很有意思的事情。我希望通过这篇文章能够让大家快速地入门Docker，并有一些学习成果来激发自己的学习兴趣。我也只是一个在Docker这条巨鲸上玩耍的小孩，全文如有不明确、不正确的地方，还请斧正。Ubuntu上安装DockerDocker的基础是Linux容器技术，因此学习Docker最好是使用Linux。这里推荐64位Ubuntu系统，因为在写此文(2015-05-28)时，Docker还不支持32位，尽管民间有些土办法可以象征性的解决，但还是推荐初学Docker的尽量按照标准的来。如果手边没有Ubuntu系统可以去Digitalocean、Ucloud等云服务商去租用一个Linux服务器。这样即使玩坏了也可以随时重新开始。在Ubuntu中只需要运行一行命令即可实现Docker的安装：sudo apt-get install docker.io运行完后，可以在终端输入docker看到下面的界面证明我们安装成功了（注：提示权限问题就添加sudo，下文同）:从上图可以看到，Docker的命令并不多，只有三十几个。例如我们可以输入docker info来查看我们安装的Docker信息:运行容器安装好之后，我们就可以来开始Docker之旅了，我们现在的Docker还是一个”裸”Docker，上面没 ...继续阅读 (24)

Git 作为一个源码管理系统，不可避免涉及到多人协作。协作必须有一个规范的流程，让大家有效地合作，使得项目井井有条地发展下去。"协作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。本文介绍三种广泛使用的协作流程：Git flowGithub flowGitlab flow如果你对Git还不是很熟悉，可以先阅读下面的文章。《Git 使用规范流程》《常用 Git 命令清单》《Git 远程操作详解》一、功能驱动本文的三种协作流程，有一个共同点：都采用"功能驱动式开发"（Feature-driven development，简称FDD）。它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。二、Git flow最早诞生、并得到广泛采用的一种协作流程，就是Git flow 。2. 1 特点它最主要的特点有两个。首先，项目存在两个长期分支。主分支master开发分支develop前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。其次，项目存在三种短期分支。功能分支（feature branch）补丁分支（hotfix b ...继续阅读 (12)

原文：The End of Corporate Computing作者：尼古拉斯·卡尔翻译：黄思路编辑：管理学人编注：原文发布于2005年20 世纪早期，有一些之前的几十年里无法想象的事情陆续发生：制造厂商开始关闭、拆除水轮设备、蒸汽机和发电机。要知道，从工业时代开始，电力就是任何产业得以运作的必要前提，工厂作坊除了维持独立发电站来使机器运作以外别无选择。新世纪的到来带了一种新的可能，许多新兴发电商开始通过建立中央电厂和使用电网给远距离外的客户输送电能。制造商本身不需要再维持独立发电站的运营，他们可以从这些新兴发电商那里购买需要的用电。几乎过了整整一个世纪后，历史再次重演。过去 50 年中最重要的一项商业成就——信息技术——正在经历类似的转变。信息技术曾以电脑、软件和其他各式各样的形式作为公司的一种资产，而现在，它正在转化为一种从供应商那里购买的服务。商业界很少有公司真正意识到这个转变的重大意义和深远影响。至今，关于效应计算的讨论也仅仅是停留在信息技术供应商的市场标语里，如同那些含义模糊的各类名词，“自动系统”、“服务及虚拟化”、“服务型架构” 等等。其实这些充满官腔的言词不仅没有着向大众照亮这一转变的未来，更使人们对于它的理解变得非常模糊。当下最盛 ...继续阅读 (9)

「我们一直这样做开发，时间做久了，便忘了当初的本意。」有关软件系统开发，我们谈些什么？我们谈过程，编码规范、开发流程、同行评审、结对编程、持续集成，从瀑布到敏捷再到极限编程。我们谈架构，企业级、J2EE、容器化、SOA（面向服务架构）、Microservices（微服务化）。我们谈规模，大容量、高并发、大数据。我们还谈可靠性、可用率、n个9、响应时间等等。。。这一切的核心是什么？先讲个电力行业的一个故事，电力的项目我没做过，对电厂的原理虽有所了解，但看见那些大规模的电站还是感觉挺复杂的。 故事是这样开始的：记得有个给我们上培训课的主讲老师是个须发皆白的老先生，进门后掏出一堆零件放在讲台上， 一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一盏小灯泡。 老先生往壶里倒了些水，点燃酒精灯，不一会儿水开了，从壶嘴里喷出了蒸汽，带动叶片旋转，然后小灯泡就亮了。他说：这就是电厂。他还说：如果烧的是煤炭，这就是燃煤电厂；如果烧的天然气，这就是燃气电厂；如果获得热能的方式是核裂变，这就是核电厂；如果带动叶片的能量来自水从高处流向低处，这就是水电厂。老先生说：你们或许会问 “那我们看到的电厂怎么这么复杂”，答案其实很简单， 电力项目需要复杂系统的目的，一是为了确保安全（Safety），二是为了提高效率（Efficiency）。安全和效率的平衡，是所有工程技术的核心。 ...继续阅读 (7)

英文原文：Conceptual Architecture of the Linux Kernel摘要Linux kernel成功的两个原因：（1）架构设计支持大量的志愿开发者加入到开发过程中；（2）每个子系统，尤其是那些需要改进的，都支持很好的扩展性。正是这两个原因使得Linux kernel可以不断进化。一、Linux内核在整个计算机系统中的位置Fig 1 - 计算机系统分层结构分层结构的原则：the dependencies between subsystems are from the top down: layers pictured near the top depend on lower layers, but subsystems nearer the bottom do not depend on higher layers.这种子系统之间的依赖性只能是从上到下，也就是图中top的子系统依赖bottom的子系统，反之则不行。二、内核的作用虚拟化(抽象)，将计算机硬件抽象为一台虚拟机，供用户进程(process)使用；进程运行时完全不需要知道硬件是如何工作的，只要调用Linux kernel提供的虚拟接口(virtual interface)即可。多任务处理，实际上是多个任务在并行使用计算机硬件资源，内核的任务是仲裁对资源的使用，制造每个进程都以为自己是独占系统的错觉 ...继续阅读 (23)

从今年2月底开通微信公众账号以来，到现在差不多9个月的时间，订阅的用户差不多有 500 人了。这个数字当然不能和那些大 V 的订阅数相比，甚至那些大 V 在文章结尾处给别人的账号做个推荐，一天的订阅数也许都会超过我的。但是，我对 500 个订阅数的结果是很满意的。记得最早开通公众号那会，我还在上家游戏公司。我离开公司前给程序组的同学做了一次关于游戏服务端开发的讲座。在演讲稿的最后一页，我贴出了我的公众号二维码。我说，我马上就要离开公司了，这是最后一次做分享了。不过，可以关注我的这个公众号，之后我的学习心得和最新动态都会在这个公众号里发出来。大家都在广州，也有的是交流的机会。所以，前公司的同事成了我的公众号最早的订阅者。即使订阅数很少，我也写的很认真，因为我明白，写公众号收获最大的不是读者，而是自己。它锻炼了我写作的能力，让我静下心来思考，通过不断的学习、思考、总结、汇集成文字，最后常常有种豁然开朗的感觉，感觉对一个东西的理解又深入了一个层次。在我刚工作第一年的时候，我就养成了写博客的习惯。仔细想了想，也许是在更早的时候就开始写博客的。我记得大四（2006年左右）那会，博客园可谓是如日中天，百花齐放。在博客园里我如饥似渴的学习着微软的技术，那时候园子里大神辈出，每每让我仰视。那时候加的 QQ 群：湖南微软开发者俱乐部，直到现在还在里面，虽然不发言，也没有被管理员踢掉，可见这是一份大家 ...继续阅读 (12)

英文原文：From Doodles to Delivery: An API Design Process要想设计出可以正常运行的Web API，对基于web的应用的基本理解是一个良好的基础。但如果你的目标是创建出优秀的API，那么仅凭这一点还远远不够。设计优秀的API是一个艰难的过程，如果它恰巧是你当前的工作任务，那么你很可能会感到手足无措。不过，优秀的设计绝对是可以实现的。本文所描述的流程将帮助你获得成功，我们将共同研究什么是优秀的设计，以及迭代式的流程如何帮助我们实现这一目标。我们还将叙述设计的三个重要阶段：草图设计、原型设计以及实现，同时还将介绍一些能够让你的工作变得更轻松的工具。优秀的API设计来自于迭代过程在开始设计API之前，我们必须理解它的目的。在你手动设计之前，你应当了解为什么要设计这个API，如果在这方面需要帮助，有许多现成的资料可以参考。不过，定义你的动机仅仅是第一步，真正的诀窍在于直到实现为止，始终保持进行正确的设计决策。成功的API设计意味着要设计出一种接口，让它的使用方式符合它的目的。作为API设计者来说，我们所做的每个决策都会影响到产品的成败。设计过程中需要做出一些重大的决策，例如API所使用的传输协议、或它所支持的消息格式。但除此之外，还有许多相关的次要决定，例如接口的控制、名称、关联以及次序。而当你将所有的决策集中在一起时，它们将带动API的使用模式 ...继续阅读 (27)

好的架构不是设计出来的而是演进出来的对很多创业公司而言，在初期的时候，我们很难在初期就预估到流量十倍以后、百倍以后、一千倍以后网站的架构会变成什么样。当然，如果在最初的时期，就设计一个千万级并发的流量架构，那样的话，成本是也是非常之高的，估计很难有公司会这样做。所以，我们主要来讲架构是如何进行演化的。我们在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题的过程中，整个战略的架构就是在不断的演进了。其实，在 58 同城建立之初，站点的流量非常小，可能也就是是十万级别，这也就意味着，平均每秒钟也就是几次的访问。此时网站架构的特点：请求量是比较低，数据量比较小，代码量也比较小。可能找几个工程师，很容易就做一个这样的站点，根本没什么「架构」可言。其实，这也是很多创业公司初期面临的问题，最开始58同城的站点架构用一个词概括就是「ALL IN ONE」，如下图所示：就像一个单机系统，所有的东西都部署在一台机器上，包括站点、数据库、文件等等。而工程师每天的核心工作就是 CURD，前端传过来一些数据，然后业务逻辑层拼装成一些 CURD 访问数据库，数据库返回数据，数据拼装成页面，最终返回到浏览器。相信很多创业团队，初期做的工作也是类似，每天写代码，写 SQL、接口参数、访问数据等等。这里需要说明一个问题，大家都知道目前 58 同城使用的是 Windows、IIS、SQL-Sev ...继续阅读 (6)

MVC 的历史MVC，全称是 Model View Controller，是模型 (model)－视图 (view)－控制器 (controller) 的缩写。它表示的是一种常见的客户端软件开发框架。MVC 的概念最早出现在二十世纪八十年代的施乐帕克实验室中（对，就是那个发明图形用户界面和鼠标的实验室），当时施乐帕克为 Smalltalk 发明了这种软件设计模式。现在，MVC 已经成为主流的客户端编程框架，在 iOS 开发中，系统为我们实现好了公共的视图类：UIView，和控制器类：UIViewController。大多数时候，我们都需要继承这些类来实现我们的程序逻辑，因此，我们几乎逃避不开 MVC 这种设计模式。但是，几十年过去了，我们对于 MVC 这种设计模式真的用得好吗？其实不是的，MVC 这种分层方式虽然清楚，但是如果使用不当，很可能让大量代码都集中在 Controller 之中，让 MVC 模式变成了 Massive View Controller 模式。Controller 的臃肿问题何解？很多人试图解决 MVC 这种架构下 Controller 比较臃肿的问题。我还记得半年前 InfoQ 搞了一次移动座谈会，当时 BeeFramework 和 Samurai-Native 的作者 老郭 问了我一句话：「什么样 ...继续阅读 (23)

这篇文章谈下编码中的一些细节问题，在谈之前首先还是要继续推荐下《代码大全》这本书，该书在很多公司都会被推荐为新人入职后的必读书，即使在互联网和敏捷开发环境下，该书对于新人仍然有仔细阅读和体会的必要，要明白架构和设计思维的基础仍然是编码思维，面向对象思维的基础仍然是代码本身的逻辑和结构，如果不能写出高质量的代码，那么架构和面向对象思想很多内容往往难以真正落地。对于这篇文章，结合一个最简单的业务功能场景来讲解，即采购订单新增这个业务功能和场景。拿到这个功能需求后当然是首先要详细阅读具体的业务功能需求，在阅读完后第一需要思考的不是业务流程，不是数据库表，而是首先应该思考该功能对应的核心领域对象究竟是什么？以这个功能为例，可以很明细的看到核心对象是采购订单，这是一个有明确业务含义的对象，可以看到后续很多的业务操作和方法都将围绕采购订单这个对象展开。核心主对象明确后再分析该功能需要依赖的附属对象，比如：供应商：基础主数据对象，依赖原因是需要在创建采购订单的时候选择供应商采购类型：数据字典类对象，依赖原因同样需要在创建订单的时候选择订购商品：基础主数据对象，一张订单在创建的时候都必须要选择购买的一个或多个商品和数量信息该问题做了基本的思考后，再回答我们具体使用的语言和开发框架，比如基于标准的java ssh框架来开发该功能，要明白我们一般选择了某种框架后基本的分层思路就已经确定了。当我们拿到一 ...继续阅读 (7)

英文原文：When Should You Avoid Commenting Your Code?看到标题，我知道你可能会想：“我为什么要避免代码注释，这难道不是一件好事吗？”。是的，写注释在大多数情况下是有用的。但是，请注意，我说的是“在大多数情况下”，因为有一些情况下，你不应该写注释。还不相信？那让我告诉你：写注释有时会坏事！会导致坏代码！请允许我用一句名言来开始我的论证：不要注释坏代码——重写吧。——Brian W. Kernighan and P. J. Plaugher这句话给我流下了非常深刻的印象。仔细想一想，有多少次你注释你的代码，只是因为担心自己将来再回过头来阅读的时候可能会不理解它的意思？至少都做过一次吧。坦率地说，我有很多次是因为这个原因才注释的，尤其是在那些我还是重构和编写干净代码的新手的日子里。那么，为什么这样的注释反而不好呢？简而言之是因为，我们会因为有注释而放任编写坏的代码！正如你所看到的，注释有时候反而激励了我们去写一些不整洁的代码。另一个原因是因为注释会误导我们。有多少次你已经改变了代码，却忘了改旁边的注释？别否认，这种事时常发生。这就是为什么你经常听到这样一句话，“真理只存在于代码中”。那么，什么时候你不应该写注释呢？有一个经验法则 ...继续阅读 (5)

互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称 CI）。本文简要介绍持续集成的概念和做法。一、概念持续集成指的是，频繁地（一天多次）将代码集成到主干。它的好处主要有两个。1、快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。2、防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。Martin Fowler 说过，"持续集成并不能消除 Bug，而是让它们非常容易发现和改正。"与持续集成相关的，还有两个概念，分别是持续交付和持续部署。二、持续交付持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。三、持续部署持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。持续部署的前提 ...继续阅读 (29)

我先做一下自我介绍，我是 2007 年加入的 Google，在 Moutain View 总部任 Google SRE，今年年初回国加入 Coding。在 Google 我参与了两个 Project，第一个就是 Youtube，其中包括 Video transcoding, streaming 等，Google 的量很大，每个月会有 1PB 级别的存储量，存储，转码后，我们还做 Gobal CDN ，最大的时候峰值达到 10 TB，我们在全球 10 万个节点，每台机器都是 24 核跑满状态。然后我从 Youtube 团队离开加入 Google Cloud Platform Team。我们做的主要工作是管理 Google 全球的机器，大概有 100 万台左右。我离开 Google 之前做的就是 Omega Project，一个集群管理系统，管理 Google 整个云平台的任务调度，协作。可能很多人会说“然并卵”，因为这是都是国内不存在的网站。(笑)从 Google 回来在 Coding 做 CTO，对我来说也是人生的一个大改变。最近我在知乎看到一个好问题，“从大公司离开到小公司当 CTO 是怎样的体验”，我摘抄了一个好答案：“ 顶着 CTO 的名号，招聘，培训，鼓励程序猿，拉网线，查机房，装系统这都是 CTO 要做的事；讨论 ...继续阅读 (8)