转:iOS应用架构谈 开篇

转自:iOS应用架构谈 开篇  http://casatwy.com/iosying-yong-jia-gou-tan-kai-pian.html

缘由

之前安居客iOS app的第二版架构大部分内容是我做的,期间有总结了一些经验。在将近一年之后,前同事zzz在微信朋友圈上发了一个问题:假如问你一个iOS or Android app的架构,你会从哪些方面来说呢?

当时看到这个问题正好在乘公车回家的路上,闲来无聊就答了一把。在zzz在微信朋友圈上追问了几个问题之后,我觉得有必要开个博客专门来讲讲一些个人见解。

其实对于iOS客户端应用的架构来说,复杂度不亚于服务端,但侧重点和入手点却跟服务端不太一样。比如客户端应用就不需要考虑类似C10K的问题,正常的app就根本不需要考虑。

这系列文章我会主要专注在iOS应用架构方面,很多方案也是基于iOS技术栈的特点而建立的。因为我个人不是很喜欢写Java,所以Android这边的我就不太了解了。如果你是Android开发者,你可以侧重看我提出的一些架构思想,毕竟不管做什么,思路是相通的,实现手段不同罢了。

当我们讨论客户端应用架构的时候,我们在讨论什么?

 

其实市面上大部分应用不外乎就是颠过来倒过去地做以下这些事情:

--------------- --------------- --------------- --------------- | | | | | | | | | 调用网络API | --> | 展现列表 | --> | 选择列表 | --> | 展现单页 | | | | | | | | | --------------- --------------- --------------- --------------- ^ | | | | | ------------------------------------------

简单来说就是调API,展示页面,然后跳转到别的地方再调API,再展示页面。

 

那这特么有毛好架构的?

 

非也,非也。 —- 包不同 《天龙八部》

App确实就是主要做这些事情,但是支撑这些事情的  阅读全文...

Posted in 技术资料 | 评论关闭

转:在全员都在投身「投资事业」的公司里工作 是一种怎样的体验?

转正微信公众号:公司精选(ID:gongsijingxuan)

(雪球ceo 方三文 雪球ID:不明真相的群众)

 
在全员都在投身「投资事业」的公司里工作 是一种怎样的体验?公司精选(ID:gongsijingxuan)
 

在这家公司赚得根本就不是工资!如果你想问为什么?请把文章看完。这简直就是一家颠覆你价值观的公司!
 
1雪球是什么?

名字出处,
巴菲特说:“人生就像滚雪球,最重要的是发现很湿的雪和很长的坡。”

 
那雪球到底是什么呢?
中国第一家从社交做交易的互联网金融公司。

不好意思,我又装逼了,我说人话:其实你可以把雪球想象成为微博,或者是Facebook。只不过在这里,大家讨论的是股票而已。你可以动态选择自己应该关注什么人,通过持续和他们交流,知道哪些人最可能解答你哪方面的问题。边交朋友边赚钱!当然不放盘的时候也会八卦,因为这完全是你的一个赚钱朋友圈!不信?你看…

 


 
2在雪球工作是一种怎样的体验?

原来总有人问:“在雪球工作是一种怎样的体验?”。我还是想用图说话:

 

这是办公环境

 

(办公室整体的设计很大胆,很有现代感。更重要的是很舒服!他们每一个地方都是打通的,阳光从不同的角度洒进来,整个办公室都暖了。刚进门的地方就会看到上面有一个投影仪,都会把每  阅读全文...

Posted in 默认分类 | 评论关闭

在线数据迁移那点事

说明:infoQ 投稿文章,刊出稿地址:在线数据迁移经验:如何为正在飞行的飞机更换引擎

博客上的文字与刊出稿有细微差别。

在线数据迁移,是指将正在提供线上服务的数据,从一个地方迁移到另一个地方,整个迁移过程中要求不停机,服务不受影响。根据数据所处层次,可以分为 cache 迁移和存储迁移;根据数据迁移前后的变化,又可以分为平移和转移。

平移是指迁移前后数据组织形式不变,比如 Mysql 从1个实例扩展为 4 个实例,redis 从 4 个端口扩展到 16 个端口,HBase 从 20 台机器扩展到 30 台机器等等。如果在最初的设计里就为以后的扩容缩容提供了方便,那么数据迁移工作就会简单很多,比如Mysql已经做了分库分表,扩展实例的时候,只需要多做几个从库,切换访问,最后将多余的库表删除即可。更进一步,在实现上已经做到全自动数据迁移,如 HBase ,就更简单了:添加机器,手工修改配置或者系统自动发现,然后,沏一杯咖啡,等待系统完成迁移。

转移是指数据迁移前后,数据组织形式发生了变化。多年前,微博平台曾经为 ID 升级做过一次数据迁移,由 @XiaoJunHong @麦俊生 操刀,将微博 id 由最初的自增算法修改为巧妙设计的 uuid 算法(http://weibo.com/p/1001603800404851831206 ),这次迁移最大的挑战是要修改数据的主键,主键本来是数据的唯一标识,它发生变化,也就意味着原来的数据不复存在,新的数据凭空产生,对于整个系统中所有业务流程,周边配套,上下游部门都会产生巨大的兼容性挑战。不过大部分数据迁移项目都不会修改主键,甚至不会修改数据本身,改变的只是数据的组织形式。比如微博计数器原本为了节约存储空间,使用 redis hash 进行存储,后来为了提升批量查询的性能,迁移成 KV 形式;又比如微博的转发列表和粉丝列表,最初都使用 Mysql 存储,后来为了更好的扩展性和成本,都迁移到 HBase 存储。

在线数据迁移最大的挑战是如何保证迁移过程服务不受影响。很多人将其比喻成“飞行过程中换发动机”“给行驶的汽车换轮胎”,但实际上并没有那么困难,一个入行一两年的技术人员,遵从一些经验指导,完全可以完成。下面就跟大家分享一下微博平台在这方面的一些经验,作为抛砖引玉。

在线数据迁移一般分为四个步骤:一,上线双写,即同时写入新旧两种数据;二,历史数据离线搬迁,即离线将历史存量数据从旧系统搬到新系统;三,切读,即将读请求路  阅读全文...

Posted in 工作日志 | 评论关闭

转:我为什么不再成长?

最近跟很多没毕业、刚毕业、或者工作3年以内的设计师聊天,了解了许多他们在不同时间点上的困惑,我想总结一些我的想法供大家参考,第一个话题是:我为什么不再成长?

成长总是一个最频繁的话题,很多在一定时间里总感觉到成长受到了限制,那么到底是什么决定了你的成长。在我看来,成长的决定因素(成长因子)有四点:

  1. 你所在组织的成长
  2. 你领导的成长
  3. 你伙伴的成长
  4. 你自己的努力程度

在这里,我把你自己的努力程度放在了最后,在我看来,依靠自己的精神力成长是最不讨巧的方式,但是事实上,很多抱怨无法成长的设计师,即没有处于一个快速成长的组织、被一个无法成长的领导管理、周围没有快速成长的伙伴、自己又缺乏自我成长的驱动力。因此,如果你认为自己没有成长,只需要问自己四个问题:

  1. 我的公司在成长吗?
  2. 我的领导者在成长吗?
  3. 我的伙伴在成长吗?
  4. 我自己的努力程度有多少?

这里并不是鼓励大家为自己寻找外部的借口,而是告诉大家成长的最佳方式是“借势”。我们往往陷入一个误区,在有意愿成长时忽视环境的影响,陷入自我学习的执拗;在成长受挫时又开始抱怨环境不好。那么如何识别公司、领导、和伙伴的成长呢?

公司成长

对于一间规模在50人一下的小公司,公司整体业务量的成长就是全部,最好的办法是和人力资源与销售人员聊天,他们掌握着一间公司的供给和需求,成长往往带来的是供需两旺,人力资源和销售往往是最忙的,听他们抱怨什么、看他们的状态可以体会到公司的成长。并不是所有公司都对员工进行财务透明,了解营收(Revenue)、净利润(Net Profit)、人均营收(Revenue Per Employee)等财务指标也是判断公司成长最直接的手段。

而对于成百上千规模的大公司而言,情况有些复杂,对于设计师而言,我指的就是互联网公司,你所需要关注的是“你所在产品线业务的成长”。作为设计师的你,一定可以判断你所在的产品处于什么样的生命周期,一个互联网产品的生命周期可以超不过五年,最旺盛的增长期也许只有一年左右,当产品成长趋于平缓,在组织级别你能获得的成长因子就越小。

领导者成长

可能很多人忽略了领导者成长的重要性。实际上这是最朴素的道理,如果你的领导者年复一年地重复一件事情,不追求更高的挑战,他就不会把他重复做  阅读全文...

Posted in 技术资料 | 评论关闭

转:Docker,云时代的程序交付方式

要说最近一年云计算业界有什么大事件?Google Compute Engine
的正式发布?Azure入华?还是AWS落地中国?留在每个人大脑中的印象可能各不相同,但要是让笔者来排名的话那么Docker绝对应该算是第一位的。如果你之前听说过它的话,那么也许你会说“没错,就是它”,因为几乎世界各地的开发、运维都在谈论着Docker;如果你还没听说过Docker,那么我真的建议你花上10分钟来阅读本文。

1. Docker简介 1.1. 什么是Docker?

Docker是一个重新定义了程序开发测试、交付和部署过程的开放平台。Docker也是容器技术的一种,它运行于Linux宿主机之上,每个运行的容器都是相互隔离的,也被称为轻量级虚拟技术或容器型虚拟技术。而且它有点类似Java的编译一次,到处运行,Docker则可以称为构建一次,在各种平台上运行,包括本地服务器和云主机等(Build once,run anywhere)。

容器就是集装箱,我们的代码都被打包到集装箱里;Docker就是搬运工,帮你把应用运输到世界各地,而且是超高速。

Docker是开源软件,代码托管在GitHub上,使用Go语言编写。Go可以称得上是互联网时代专门为开发分布式、高并发系统而生的编程语言。Docker也可以说是Go语言的一个杀手级应用,而且在Docker生态圈里很多软件也都是使用Go语言编写的。

1.2. Docker历史

Docker项目始于2013年3月,由当时的PaaS服务提供商dotCloud开发,dotClound也是YCombinator S10的毕业生。尽管Docker项目很年轻,到现在也只有15个月而已,然而它的发展势头如此之猛已经让很多人感叹不已了。

2013年10月dotCloud公司名字也由dotCloud, Inc.改为Docker, Inc.,集中更多的精力放到了Docker相关的研发上。

1.3. Docker的技术基石

在进入Docker的世界之前,我们先来看一下Docker实现所依赖的一些技术。

实际上Docker的出现离不开很多Linux kernel提供的功能,甚至可以说Docker在技术上并没有什么特别重大的创新之处,利用的都是已经非常成熟的Linux技术而已,这些技术早在Solaris 10或Linux Kernel 2.6的时候就有了。可以毫不夸张的说Docker就是“站在了巨人的肩膀上”。

下面我们就先来了解一下Docker主要利用的Linux技术。

1.3.1. 容器技术

容器(Container)有时候也被称为操作系统级虚拟化,以区别传统的Hypervisor虚拟技术。它不对硬件进行模拟,只是作为普通进程运行于宿主机的内核之上。

阅读全文...
Posted in 技术资料 | 评论关闭

丰田生产方式的启发

众所周知,日本车在全世界都是很受欢迎的。究其开端,很多人会想到20世纪70年代的石油危机,认为是油价高涨,为尺寸小、油耗低的日本车打开了市场。这固然可以解释一部分原因,但另一方面,为何日本车能够持续受到欢迎,为何日本车能摆脱“价廉质差”的形象,既有优惠的价格又有优异的品质(缺陷率常年很低)。这一切,都与日本汽车厂商所采用的“精益生产”,尤其是丰田开创的“丰田生产方式”(Toyota Product System, TPS)有很大的关联。最近因为与供应链打交道很多,我花了些时间学习这种生产方式。有趣的是,我发现,它的价值不只限于汽车行业,甚至不只限于制造业,对其它许多行业(包括软件行业)。所以下面我讲讲丰田生产方式给我的启示。

 

“丰田生产方式”给我印象最深的要求是,员工必须同时对工作和工艺负责。自从福特发明了“流水线”之后,工人似乎成了机器的附庸,只是完成机器暂时无法完成的工作。生产的终极形态,就是把一切工作变成简单重复劳动,用机器执行。所以,工人的工作也应该简单机械,比如每天按照生产线的运作,以一定节奏拧紧某个螺丝,就是一种典型。而在丰田生产方式下,工人不但要完成简单机械的本职工作,还必须对工艺负责,也就是理解该工作的意义,思考并不断思考改进自己的工作过程——他们既有这个义务,也有这个权力。结果,整条生产线就好像具备了不断改进的活力,而不再由少数专职的“专家”负责优化(实际上专家也负不了那么多责任)。

软件开发/互联网虽然看起来是光鲜亮丽的高科技行业,但不少时候是达不到这种要求的。许多公司并不要求员工去思考和改进,许多员工也更愿意只做简单重复劳动,不愿意开动脑筋去思考和改进自己的工作。所以,无论是工作质量还是工作效率,其实都停留在相当低的水平上。而许多公司的解决办法,无非是找一些“技术牛人”来负责,这就好像汽车生产厂找“工艺专家”来优化生产一样,或许有效果,但不会太明显。与“对工作和工艺负责”的工人类似,有些程序员会积极开动脑筋编写或者学习一些工具软件来改进自己的工作,他们或许不能编写复杂的框架或精深的算法,但确实堪称优秀的程序员——就好比生产线上优秀的工人。可以说,如果公司的大部分员工都具有这样的意识和习惯,公司也支持和提倡这样的工作方式,那么其产品一定不会太差。

“丰田生产方式”中的还有一点要求,即员工一定不能只了解自己的工作  阅读全文...

Posted in 技术资料 | 评论关闭

分布式系统的事务处理

当我们在生产线上用一台服务器来提供数据服务的时候,我会遇到如下的两个问题:

1)一台服务器的性能不足以提供足够的能力服务于所有的网络请求。

2)我们总是害怕我们的这台服务器停机,造成服务不可用或是数据丢失。

于是我们不得不对我们的服务器进行扩展,加入更多的机器来分担性能上的问题,以及来解决单点故障问题。 通常,我们会通过两种手段来扩展我们的数据服务:

1)数据分区:就是把数据分块放在不同的服务器上(如:uid % 16,一致性哈希等)。

2)数据镜像:让所有的服务器都有相同的数据,提供相当的服务。

对于第一种情况,我们无法解决数据丢失的问题,单台服务器出问题时,会有部分数据丢失。所以,数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储(一般工业界认为比较安全的备份数应该是3份,如:Hadoop和Dynamo)。 但是,加入更多的机器,会让我们的数据服务变得很复杂,尤其是跨服务器的事务处理,也就是跨服务器的数据一致性。这个是一个很难的问题。 让我们用最经典的Use Case:“A帐号向B帐号汇钱”来说明一下,熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作:

  1. 从A帐号中把余额读出来。
  2. 对A帐号做减法操作。
  3. 把结果写回A帐号中。
  4. 从B帐号中把余额读出来。
  5. 对B帐号做加法操作。
  6. 把结果写回B帐号中。

为了数据的一致性,这6件事,要么都成功做完,要么都不成功,而且这个操作的过程中,对A、B帐号的其它访问必需锁死,所谓锁死就是要排除其它的读写操作,不然会有脏数据的问题,这就是事务。那么,我们在加入了更多的机器后,这个事情会变得复杂起来:

 

1)在数据分区的方案中:如果A帐号和B帐号的数据不在同一台服务器上怎么办?我们需要一个跨机器的事务处理。也就是说,如果A的扣钱成功了,但B的加钱不成功,我们还要把A的操作给回滚回去。这在跨机器的情况下,就变得比较复杂了。

2)在数据镜像的方案中:A帐号和B帐号间的汇款是可以在一台机器上完成的,但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作(要汇给B和C),这两个操作发生在不同的两台服务器上怎么办?也  阅读全文...

Posted in 技术资料 | 评论关闭

CTO这点事

 

转自:曹政 @zhihu http://zhuanlan.zhihu.com/iamcaoz/19856992

 

几乎整个互联网行业都缺CTO,特别是一些草根背景的创业者,这个问题更加显著。从我自己的感受,身边各种朋友委托我找CTO的需求,嗯,算下来超过两位数了,光最近一个月就有3个,而且这三家都是刚拿了A轮的。其他那些公司CTO大部分空缺了一两年,或者其他高管临时暂代过渡。实话说,我觉得每个公司都不错的,但通常也只能遗憾的说,真没有能推荐的。

其实,根据个人的观察,每个互联网团队都喊需要CTO,但是具体诉求却各不相同,如果说共性,就只有一点,那就是,公司老板对技术的期望值与目前技术团队的能力表现,有较大的差异,而这个差异,对于老板来说,就是一个想法,找个合格的CTO,一切就都解决了。其实,真不是这回事。

今天要说的第一点,就是期望值的控制;很多互联网公司都希望自己走技术驱动的路线,期望小而美,复制美国技术新贵的市场表现;这不能说是一个错误的期望,但是,现实能有多少符合这种需求的人才呢?这样的人才需要技术有前瞻性,对产业格局有判断,对管理有心得,情商还不能低(算了一下,四项里我至少三项不符合。)。整个行业内这样的人有几个?凭什么会跟你? 事实上我身边确实有这样的案例,一个以业务为主的公司,搞定了一个超棒的CTO,很快就转型成以技术为驱动的公司,公司价值极大提升,问题是,这种现象很难具有复制性。

下面我说一下一个最基本的让人纠结的问题,到底什么是CTO?其实,空谈这个名词的定义毫无意义,从我身边很多朋友公司的实例来看,他们对这个角色的定义和定位是差异非常大的。具体而言,不同创业团队,对CTO需求的真实想法,包括如下层面。

技术选型,这其实是创业公司最纠结的问题;他们往往一上来基于已有的程序员的个人习惯和爱好,选择了一个技术方案,然后到某一天一看,我靠,全是坑(当然,也可能与执行者的能力有关)。而更糟的是,这个技术方案相对冷门,市场上去招聘都很难做。还有就是技术方案成本过高,(不只是钱的问题,特别是时间成本!)结果严重影响到后续的发展速度。 我举个简单例子,最近我给多个创业者提建议,比如做app,很多以内容运营为核心的app,不要用原生态开发,目前一堆第三方的跨平台开发架构,如果选择合适,可以极大减少开发成本,以及降低技术招聘的难度。微信开店开社区,也有一堆第  阅读全文...

Posted in 技术资料 | 评论关闭

架构选择和团队影响

转自:https://www.linkedin.com/today/post/article/20140920230659-284548454-%E6%9E%B6%E6%9E%84%E9%80%89%E6%8B%A9%E5%92%8C%E5%9B%A2%E9%98%9F%E5%BD%B1%E5%93%8D

架构选择

架构是协作基础。架构层面的基本决策深刻影响着团队学习/协作的方式和效率。

在这里,我想尝试探讨技术架构有关的一些选择对团队工作的影响。题目有点大,希望我能在小心控制范围的同时,又不失深度。

 

1、对开源的使用和态度

要不要使用开源软件?以何种方式/态度对待开源和社区?

如今的软件/互联网企业,相信已经很难找出不使用开源软件/库的了,但对待开源的态度,差别还是很大。

 

有些人可能一直用着开源软件,但从不关心它的源码,更别提参与开发、做出贡献;而有的人则会仔细的研究代码,对设计水平和代码质量作出自己的判断,能够更好的调整/适应自身项目的需要,并且以 bug 报告、提交补丁、提出建议、讨论需求的形式回馈社区。

在一个封闭的、和开源社区鲜有接触的企业里,重复发明的轮子很常见;而在一个开放的、拥抱开源的企业里,则会把更多精力放在广阔世界里的发现、评估、创造、改进上,尽量不在重复发明轮子上浪费时间。

 

开源对团队的影响,就是积极参与/拥抱开源的团队,

  • 投入更有效,不会大量浪费在重复发明轮子上;
  • 视野更开阔,对技术/软件的认识更精湛;
  • 团队的沟通/协作更开放、更高效(注:和对代码相当了解的人讨论问题,比起对代码所知了了的人,当然更高效;而开源所体现出来的开放和坦诚,也更容易赢得信任和尊重)。

 

对于团队拥抱开源后的提醒,主要在于两点:

  • 对发散的精力/兴趣的重新聚焦,聚焦于产品、目标、质量和进度等
  • 开源世界里选择众多,深刻了解才能作出明智选择

 

2、代码组织和存取

是所有代码集中存放在一个大源码仓库,严格控制签入签出;还是不同模块/项目代的码存放不同的源码仓库,各自管理签入签出?

 

这个问题看起来不起眼,但其实影响巨大,请让我细细分  阅读全文...

Posted in 技术资料 | 评论关闭