做为日活近8亿推出的重磅产品，小程序尚未出生就获得了前所未有的关注。而张小龙在特意在致敬乔布斯的1月9日正式发布，也表明了在微信方、腾讯方对小程序的重视程度。至今网络上有关小程序的各种文章满天飞，其实对于更多的产品经理、创业者、实体店主等潜在的受益人群关心的则是，小程序机会来了，我们该如何做？对于他们来说，小程序的意义？小程序对腾讯的战略价值？小程序对移动生态的颠覆性？似乎并不太重要，而如何利用好这个机会，在日活8亿的微信平台上，为自己的公司、实体店创造效益才是最关心的所在。定位背后三大特点：轻为上、不沉淀用户及数据、服务直接微信官方对其8个字的定位：触手可及、用完即走。既然要想在微信平台上借助小程序分享流量，就要掌握微信官方对其的定位，这样才会事半功倍，不至于开发到一半突然发现，自己的产品逻辑同小程序生态框架向冲突。这八个字决定了小程序要的是快响应、短服务。另外，社交应用占据了人大量的生活，社交用户一个最大的特点就是耐心不足，毕竟聊天才是其第一要义。所以做小程序首先要定一个基调，就是快响应与短服务，任何与之冲突的服务和内容应该弃掉或进行缩减后置。因其定位，圈定了小程序三大特点：轻为上、不沉淀用户及数据、服务直接轻为上：张小龙一直坚持一条产品理念“让用户用完即走”。这句话的意思不是要微信功能减少，第一个表达了微信在功能扩展方面的谨慎，二基本逻辑是凡用户不喜欢的功能一定不对用户产生骚扰。其实简单的来说，就是保护微信社交主功能，虽然我开发生态需要把微信变重，但社交核心不能碰。这导致小程序一定是轻为上，比如打开滴滴出行原生App可看到、出租车、顺风车等主菜单，主页还显示周边车辆等。滴滴出行小程序里的主页，就是最直接的出发地、到达地输入框与呼叫专车的按钮选项。所以说，小程序开发一定要以轻为主，只提供用户第一需要服务，而且设计上要尽量砍掉所有无关枝节。不沉淀用户及数据：正因为崇尚用完即走，这导致小程序是无法沉淀用户及数据。一旦发生用户或数据的沉淀，小程序之小就没有意义。另外，社交平台上用户频繁切换回聊天主页的这习惯，也让小程序沉淀用户的举措流产，加之不能对外跳转限制了对外引流。因此，有关从产品设计上存留用户的考虑自然就能免则免，既然不沉淀用户，类似粉丝运营类的功能就没有增添的必要。由于小程序和第三方后台是可以打通，大数据虽然无法在小程序上沉淀，但可以从打通的应用下手。服务直接：随着移动互联网的成熟，App开发上越来越趋于全面、深度的细节化，这导致App的功能越来越繁复。但这不能照搬到小程序上，小程序要做到的就是服务直接，解决单一任务。而且小程序的体量被严格限制在1M以内，想要在这1M内办完你的事，只有让你的服务极致化的简单。大公司、创业者、实体店主该如何定位小程序？在这三大特点的限制下，如何更好地发挥微信小程序的作用，为自己所用？不同的对象有着明显不同得思考，小程序作为微信沉淀流量连接一切的产品，开放的是所有加入者都可为用户提供所需，封闭的是这些流量不能从微信平台流失。根据小程序轻为上、不沉淀用户及数据、服务直接的三大特点，大公司、创业者、实体店对小程序的定位也有差异。大公司做小程序要直接变现：从如今大众点评、猫眼、滴滴出行等小程序的使用来讲，都是直接将主服务展现在首页，提供用户最需要的几个核心功能，快速实现用户在平台上的交易。既然不能沉淀用户，又无法把流量从微信内转到自家产品App里（想绕过微信规则的大公司，请参考支付宝吱口令被封杀的前车之鉴），那就直接利用微信上的流量实现用户变现，则是大公司对小程序最为首的考虑，因为包括引流、营销（对用户眼球骚扰）等其他需求都触动了微信根本的利益。创业者做小程序要转化用户：与大公司不同，他们有充足的流量，原生App丰富的功能性不怕被小程序取代。所以制作小程序只不过是服务好App上核心用户之外，服务微信上的长尾用户。对于创业者来说，他们大多有自己的独立App，大多缺乏流量，既然小程序上无法实现独立生态的愿望，把流量引出来的宝贵性不言而喻。因为小程序用完即走的特性，创业者在微信平台上想要沉淀用户、沉淀数据几乎没有任何可能。如果自己精心打造的小程序沦为微信用户想起来就用一下的工具，却无法沉淀和转化深度，这样开发小程序的意义就不高。好在创业者数量众多，不像大企业树大招风，小程序开发时就要想好如何在微信规则之内的，给自己的产品引流做铺垫。最好的办法是提供阉割版但体验极佳的功能，这样吸引大批用户之外，为了获得其他服务，即使没有外站跳转的设置，依然能够实现用户转化。实体店主做小程序要把它当做独立App来运营：相比之下，实体店主最为纯粹，他们不像创业者有着打造独立App的野心。在App爆发的时代，实体店独立制作App的热潮并未出现，成本因素是最大的障碍，运维能力欠缺也是问题所在，而且实体店的触网需求往往比较简单，小程序的出现，反而对他们来说最有价值。对于实体店主来讲，要把小程序当做独立App来打造，在小程序框架内实现不太多的如会员积分、折扣促销、预定、外卖等服务等完全够用。你是一家餐馆，可以根据自己的特色来开发小程序，比如让用户扫描餐桌上的二维码实现远程点餐和支付，让用户免去排队点餐和付账之苦。如果你是家服装店，可以对社区周边的用户推广会员积分制度，平常服装店发的会员、积分卡往往会被丢掉或麻烦不使用，但小程序来承载这个功能完全够，用户不用随时想着拿一个卡或一个独立的app应用，到店时扫扫二维码即可。总结来说，小程序将替代的是用户手机里不常用却偶尔非常需要的长尾App，对于大部分独立App来说冲击力并不大。然而微信开放小程序对于更多的公司来说是个好事，毕竟有了入口去分享微信庞大的流量。但在做小程序时要切记它的三大特点，如果违背其特色有了过高的要求，除了带来失望可能还会让你失去机会。
投诉欺诈商家:
天津重庆哈尔滨沈阳长春石家庄呼和浩特西安太原兰州乌鲁木齐成都昆明贵阳长沙武汉郑州济南青岛烟台合肥南京杭州东莞南宁南昌福州厦门深圳温州佛山宁波泉州惠州银川
本城市下暂无经销商
下载中关村在线Android 客户端
下载中关村在线 iPhone 客户端
下载中关村在线Windows8客户端
成为中关村在线微信好友当前所在位置： >
热门微信号：
创业公司应该招聘什么样的人?
作者： 浏览数：0 用手机扫描二维码
阅读，只需一秒。精彩，尽在掌握！我最爱的 Pink Floyd 乐队居然正式解散了… 先听首歌吧:创业公司应该招聘什么样的人? 已经有无数人写了无数篇文章讨论这个话题...
我最爱的 Pink Floyd 乐队居然正式解散了… 先听首歌吧:创业公司应该招聘什么样的人? 已经有无数人写了无数篇文章讨论这个话题，人云亦云岂不是浪费时间?我先来说一下我的结论：创业公司应该招聘心理上的「成年人」，确切地说，招聘心智成熟的人。当然，所有公司不可能雇佣童工，招聘到的员工都是成年人，具备基本的工作能力与知识。但这些人的差异在于，很多人只是生理上成年，心理上还是未成年人，心智尚未成熟，甚至心智成长已经停止。而有些人心理成长更快，心智成熟度更好。这些人更适合在创业团队。心智成熟与否与年龄有关，但年龄并不是一切。有些人会在结婚生子或是经历更多人生历练、挫折之后迅速成长。心理上的成年人才有资格去管理一个团队。管理心智成熟的人会很轻松，这类人的明显特征是能够自我管理自我驱动，困难面前能愈挫愈勇。但是心智不够成熟的人，就需要管理者扮演「大人」的角色，付出额外的管理成本，去「取悦」他们，不断的发给他们「糖果」让他们满意，不满意不干活儿，还会产生各种无端的怨言。很多人说，创业团队应该招聘一流的人，但全民创业的时候，一流的人在哪里? 问问你自己是一流的人才吗？如果你都算不上一流的人才，一流人才为什么会来你这里?所以我的建议是，去寻找那些心智更成熟的人，他们的扩展能力会让人吃惊。时机来临，他们在实践与磨练中会成长为不折不扣的一流的人才。你我皆应如此。题图: (C) Ming H2 Wu/Blend/Gaopinimages近期其他文章：
手机版地址：
微信号：WebNotes
小道消息，只有小道消息才能拯救中国互联网；只有小道消息才能拯救中国创业者。不关注小道消息，关注谁？
TA的热门文章
推荐互联网微信帐号
热门文章排行
(), All rights reserved 京ICP备号-12创业公司工程师应该掌握的可伸缩Web开发技术
发表于 10:46|
来源《程序员》杂志|
作者李智慧
摘要：本文面向创业公司的工程师，介绍可伸缩的Web开发技术。伸缩性是指系统可以根据需求和成本调整自身处理能力的一种特性。伸缩性意味着系统可以满足更多用户访问处理更多数据且不会对用户体验造成任何影响。
近些年来，越来越多的行业开始和互联网结合，诞生了越来越多的互联网创业公司。互联网创业公司需要面对许多的不确定因素。如果你和你的小伙伴们够幸运，你们的公司可能会在几个星期之内让用户数、商品数、订单量增长几十倍上百倍。一次促销可能会带来平时几十倍的访问流量，一次秒杀活动可能会吸引平时数百倍的访问用户。这对公司自然是极大的好事，说明产品得到认可，公司未来前景美妙。
但是快速增长的用户和订单却对公司的技术提出极大的挑战。受计算资源本身的限制，一台服务器能启动的线程数、能存储的数据，每秒钟能完成的计算、能读写的数据、能传输的数据都是有限的。而系统处理每一个用户请求都需要消耗一定的计算资源，当大量的用户同时来访问系统的时候，会出现因计算资源不足而导致的响应延迟以及超时出错，当并发访问用户超过某个极限，甚至会导致服务器宕机，整个网站不可访问的惨剧。
当公司正在为用户增加订单量上升而庆祝的时候，却传来系统崩溃网站不可访问的噩耗。喜剧变成悲剧，庆祝会变成批斗会，作为负责公司技术的工程师，作为批斗会的主角，你，是否会觉得压力山大。
本文面向创业公司的工程师，介绍可伸缩的Web开发技术。伸缩性是指系统可以根据需求和成本调整自身处理能力的一种特性。伸缩性意味着系统可以改变自身的处理能力以满足更多用户访问处理更多数据而不会对用户体验造成任何影响。
一、构建可伸缩的Web架构
互联网创业的一个特点是开始的时候规模都很小，几个人的小团队，少量的启动资金，就开始创业了。Google是从斯坦福的实验室开始创业的，Facebook是从哈佛的宿舍里开始创业的，Alibaba是从马云家的客厅开始创业的。刚开始的时候，用户也少，所以只要一台服务器就可以应付所有的用户访问，这时整个Web系统架构如图1。数据库、Web应用、文件服务都部署在一台服务器上。
图1 互联网创业早期最简单的Web系统架构
如果创业方向正确，产品解决用户痛点，能为社会创造价值，就会有更多用户来访问网站。这时，Web系统受计算资源不足影响，会出现响应延迟，打不开网站等情况。解决方法有两种，一种方法是使用更强大计算能力的计算机，另一种方法是使用更多的计算机。第一种方法主要问题在于再强大的计算机也都有资源限制，而一个成功的网站的终极目标是服务全世界，随着网站的发展，不管多强大的计算机迟早也会遇到计算资源不足的问题；而且越强大的计算机其价格也越昂贵，这也是刚刚起步的创业公司不能承受的。所以几乎所有的互联网公司都选择了第二种方法，即构建一个弹性可伸缩的Web系统，通过逐步向系统中增加服务器从而提高整个系统的计算处理能力。
增加服务器的一个基本手段是将不同的服务部署在不同的服务器上，应用服务器，数据库服务器，文件服务器独立部署，如图2。
图2 进行简单拆分独立部署的Web系统架构
此外，还可以将不同的模块拆分到不同的服务器。比如一个电子商务网站，商城、论坛、卖家这些相对独立的模块可以独立部署，即使在商城系统内部，首页、商品列表、商品详情、订单等子模块也可以进一步独立部署，如图3。
图3 按功能模块进一步拆分独立部署的Web系统架构
事实上随着业务不断发展，网站需要使用更多的服务，缓存、消息队列、搜索、NoSQL、反向代理等，还需要将静态内容服务从应用服务器中分离出来，以及使用CDN（内容分发网络）进行静态内容访问加速。这些服务都应该部署在独立的服务器上，通过使用更多的服务器提高网站的整体处理能力。
这些可以分拆的功能和服务虽然已经独立部署，但是每个功能或者服务如果只能部署在一台服务器上，能够提供的计算能力以及能够处理的并发访问依然有限。解决方法是通过集群的方式将单一服务部署在多台服务器上，从而提供更强大的处理能力，如图4。
图4 集群部署的Web系统架构&
总之，可伸缩网站架构的核心思路就是通过分拆集群等手段向Web系统中添加各种服务器，为系统提供更多计算、存储、传输能力，这些服务器能有效分担系统访问压力，使Web系统能够支撑更多用户访问、存储更多数据而不至于影响用户体验。
二、使用可伸缩的基础技术产品
前面提到，单一服务或者应用需要通过集群的方式提供更强大的计算处理能力。集群即多台服务器部署相同应用或服务构成一个服务器群统一对外提供服务。如果有更多用户访问，需要处理更多并发访问请求的时候，只需要向集群中添加新的服务器即可。这就要求服务或应用本身具有可伸缩性。
1. 通过负载均衡实现应用服务器可伸缩
应用服务器一般指部署核心业务逻辑，主要处理用户请求的服务器。应用通常设计成无状态结构，即应用本身不记录用户请求的上下文信息，这样设计的好处是任何用户的任何一次请求都可以交给任何一个应用服务器去处理。实践中，一般通过负载均衡服务器将一组应用服务器构建成一个集群，如图5。
图5 通过负载均衡实现应用服务器可伸缩（图片来源《大型网站技术架构：核心原理与案例分析》）
首先在负载均衡服务器上配置所有的应用服务器信息，用户请求先到达负载均衡服务器，负载均衡服务器通过某种负载均衡算法计算得到一个应用服务器的网络地址，然后将请求数据包转发给这个应用服务器，由该服务器完成用户请求处理。如果用户数增加，并发请求超过现有集群的处理能力，只需要在现有应用服务器集群中增加服务器，在负载均衡服务器上增加新的服务器配置信息，部分用户请求就会转发到新增服务器上，实现分担集群访问压力的目的。
负载均衡服务器的实现有很多种，DNS负载均衡、HTTP重定向负载均衡，HTTP转发负载均衡、IP层负载均衡、数据链路层负载均衡等，实践中，中小网站多使用Nginx等反向代理服务器实现HTTP转发负载均衡，而规模稍大以后则基本都使用LVS实现IP层负载均衡或者数据链路层负载均衡。目前越来越多的网站使用云服务部署网站，这些云服务也提供负载均衡服务，背后使用的技术依然是LVS或者HTTP转发。
2. 通过远程分布式缓存实现缓存可伸缩
缓存是改善网站性能的最重要手段，一方面缓存使用内存存储数据，可以更快速地响应请求；另一方面大量数据访问请求通过缓存返回，减少数据库压力，进一步改善性能。目前网站中大量使用的缓存服务是Memcached或者Redis。Memcached分布式缓存访问模型如图6。
图6 Memcached分布式缓存访问模型 （图片来源《大型网站技术架构：核心原理与案例分析》）
应用程序通过Memcached客户端访问Memcached服务器集群，其中路由算法模块负责根据应用程序输入的KEY计算得到应该访问哪台服务器，然后通过通信模块从对应服务器上读写数据。
如果Memecahed集群需要缓存更多数据或者需要提供更高的并发访问，只需要向集群中增加新的服务器，然后修改客户端服务器列表即可应用程序访问到新加的服务器。
需要注意的是如果路由算法选择不当，比如使用余数Hash算法，会出现加入一台服务器而导致现有的缓存数据大量访问不能命中的情况，其后果相当于缓存服务器集群整体宕机，给系统带来灾难性后果。目前Memcached主要采用一致性Hash算法，这种算法可以使加入新服务器对现有数据访问影响最小。而Redis通过一种类似虚拟节点的映射算法也可以达到相似的效果。
3. 通过主从复制和分布式数据库实现数据库可伸缩
目前各种网站主要使用的关系数据库是MySQL，MySQL支持数据复制功能，使用这个功能可以对数据库进行简单的伸缩。图7为使用数据复制的MySQL集群伸缩性方案。
图7 通过主从复制实现简单伸缩性的MySQL集群 （图片来源《大型网站技术架构：核心原理与案例分析》）
在这个方案中，虽然多台服务器部署MySQL实例，但是他们的角色有主从之分，数据写操作都在主服务器上，由主服务器将数据同步到集群中其他从服务器，数据读操作及数据分析等离线操作在从服务器上进行。
主从复制只能通过增加有限的几台服务器分担数据库的访问压力，如果数据库需要记录数千万上亿条记录，需要应对每秒数十万次访问压力，那么主从复制是远远不够的。这种情况下，可以考虑使用更具伸缩性的各种NoSQL数据库产品，如HBase等，也可以考虑使用分布式数据库。分布式关系数据库则通过一个代理层将数据分片并经过路由后写入一个关系数据库集群中。
除了应用、缓存、数据库，其他的服务，诸如搜索、消息队列等也可以以类似的思路和方案实现集群可伸缩。
三、打造可伸缩的技术团队
创业公司刚开始时，通常不过两三个工程师，围绕核心业务，开发一个简单的版本就发布上线开始运营了。随着业务不断发展，服务器数量必定是越来越多、技术越来越复杂，对应的，公司规模也是越来越大，工程师团队越来越多人。一般说来，一家互联网公司能做到上市，工程师团队的人数大概从数百人到数千人不等，技术团队规模和创业时相比扩大数百倍。这就要求必须有效组织工程师团队，打造可伸缩的技术团队，使技术团队的成长和公司业务成长、技术水平进步保持一致。
1. 团队拆分
制约一个团队人数规模的主要因素是沟通路径，沟通路径越多，信息传递越慢，传递过程中引入的噪音越多，团队越趋于混乱。一个5人团队，沟通路径是10=(5*4)/2，一个9人团队，沟通路径是36=(9*8)/2，沟通路径随团队规模呈指数级增长。所以当技术团队人数增长到一定规模，和构建可伸缩的Web架构中需要对服务进行拆分一样，需要对团队进行拆分，将一个大团队拆分成几个小团队，使每个小的团队保持一个比较少的人数。
团队拆分有两种方案，一种是按职能拆分，前端工程师、后端工程师、测试工程师、运维工程师、数据仓库工程师各种工程师分别构成一个个的小团队，这种拆分的好处是团队结构比较稳定，团队成员都是使用同样技术的“自己人”，团队内部沟通交流更快速高效；带来的问题是开发过程是按照产品和项目组织的，而开发一个产品需要用到前端、后端、测试、运维各种工程师，开发过程会遇到各种跨团队的交流与合作，带来更多的沟通成本。另一种是按照产品和项目拆分，团队围绕产品展开，每个团队内部拥有开发维护一个产品所需的各种技术角色，从开发到测试发布运维都在团队内部搞定，不需要太多跨团队合作，这种拆分也存在一些问题，特别是创业公司早期，产品不稳定，管理层决定要上一个新产品，于是迅速招人开发，但是很多时候产品刚上线不久甚至还没上线，管理层的决定又有变化，产品不做了，团队解散，这种朝令夕改会对技术团队造成较大伤害，所以某些互联网公司特别将“拥抱变化”上升到公司价值观高度，让员工对这种情况做好心理准备。
对于公司而言，前一种方案带来的问题是沟通低效、人员冗余、开发进展缓慢；后一种方案带来的问题是员工情绪低落影响士气。显然前一种方案对公司发展影响更大，所以实践中，更多公司采用后一种团队组织方式。为了应对这种方案带来的消极影响，公司会积极组织各种培（xi）训（nao），提供各种员工福利员工关怀，让员工忘记各种不快，投入到下一个产品开发中。不过对创业公司而言，从本质上，员工利益和公司利益是一致的，只有公司活下去、做大做强，所有人才能更好的获益，不过这也要求创业公司尽可能做到决策透明，让所有员工能理解管理层的决定，并自觉维护、执行管理层的决定。
2. 保持敏捷
创业团队白手起家，不但表现在缺资金缺用户缺人才，也表现在缺管理缺标准缺规范，于是采用各种“野路子”的管理手段。但是公司发展到一定规模，这些手段就开始捉襟见肘，出现各种问题，于是公司开始从各种名企外企引入各类『管理人才』，进行规范化管理。不过在这个规范化的过程中，有时候会出现某种矫枉过正，导致公司僵化笨拙，还没成为大公司却得了一堆大公司的病。
举两个极端但是真实的例子。某公司要求代码单元测试覆盖率必须达到一定比率，并且写了工具专门扫描工程师提交的代码是否达到要求的单元测试覆盖率，于是就看到有些工程师为getXXX和setXXX方法写测试用例。某公司要求设计阶段必须写设计文档，并提供了设计文档模板，这个模板有一章叫做『数据库设计』，某个项目不需要数据库，因此设计文档不通过评审，为此工程师不得不设计了一个永远不会用到的数据库。
某位伟人曾经说过：教条不如狗屎，狗屎可以肥田，教条屁用没有。有些『管理人员』自己不曾在一线实践过，却为一线人员制定各种规章制度，效果可想而知。对创业公司而言，最好的管理不是流程规范，而是最佳实践。某个项目迭代管理做得好，某个项目设计文档写得好，拿来在全公司分享，大家一起学习改进，在实践中提高，产生更好的实践继续分享。从实践中来到实践中去，而不是从PPT来到Word中去。
本文限于篇幅，概要描述了Web应用可伸缩架构技术，期望创业公司工程师在创业早期就能明了网站技术发展的一般模式，更好地规划自己公司的技术发展道路。关于网站可伸缩架构的更多技术细节，可以根据这篇文章提到的技术点按图索骥阅读更多资料，更重要的当然是在实践中学习，随着公司逐步壮大，自己也逐渐成长为网站技术方面的卓越人才。期待未来最伟大的互联网公司出现在中国，期待未来最顶尖的互联网技术人才出现在本文的读者当中，祝福大家。
作者简介：目前任职宅米网CTO，曾供职阿里巴巴与英特尔亚太研发中心，从事大型网站、分布式系统、大数据平台方面的研发工作。著有《大型网站技术架构
核心原理与案例分析》一书。
【相关阅读】
，关注架构和算法领域，寻求报道或者投稿请发邮件，交流探讨可加微信qshuguang2008，备注姓名+公司+职位）
本文来自《程序员》电子刊10月B架构专题文章，，包含：iPad版、Android版、PDF版。
值得一提的是，由CSDN举办的
将于11月19-21日在北京举行，本次大会涵盖：新型数据库、编程语言、工具与平台、产品与设计、前端开发、算法、微信开发、架构实践、安全等九大分
论坛，届时国外知名讲师将分享所在领域的最佳实践。【】
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章}