摘要

一个好的互联网架构，最基本的应该具备高可用，可扩展，容错。安全性退居至具体的业务属性

持续改善释放生产力

架构，落地就注定不完美。持续改善，释放生产力，才能趋于完美。

截止到2015年05月20日凌晨0点0分中国移动智能终端用户(设备)数:1,438,139,921台(参考:talkingdata).十年前QQ用户量不上亿，五年前还没有微信，小米也刚成立。今天，微信装机量排名第一，小米手机杀入全球三甲。BAT，纷纷布局。传统企业热情拥抱互联网，开启一个互联网+的时代。

人人都想参与其中，身边有些同事也纷纷投入创业的大营，或供职于互联网创业公司。强势炒作，并购抱团。当这所有的招式用尽，瓜分用户流量之后，剩下的问题就是：怎样给用户提供一个好的服务？

好的架构不是一蹴而就的，它是跟随业务演变逐渐成长起来的。

架构演变

一切看似美好的事物，并非原貌就如此。这个句势可以一直造下去… 无非就是向自然人揭示”千里之行始于足下”的道理。今天借此机会谈谈移动互联网下的系统架构。

量的挑战与 7 * 24 * 365

服务质量的度量(service metric)

用户体验的最后一公里

传统软件

早些年做企业软件时，感觉就是给甲方做各种点点点的工具，单想这件事真的巨无聊。当看到车间大屏上的信息提示，操作工手上的扫码枪，心中的自豪感又油然而生。—— 满满是爱。

架构策略：

数据读写分离报表类业务采用单独的库
应用垂直集群避免业务应用崩溃导致的服务不可用
解耦第三方它们有时并不靠谱提前做准备

做完这些以后，只要服务不死，对外就可以宣称7 * 24 小时服务。然后在做点花里胡哨的东西，蒙骗下小白客户，基本上就衣食无忧，无非就是要陷入各种各样项目的深坑中无法自拔，最后自己把自己整的身心疲惫。

这不算架构失职，企业信息化传统软件厂商大环境下生存的策略就是：快速复制，做类似的项目。平台化开发提示，降低研发成本。

以上纯属个人对过往从业的认识，不含任何偏见，只求一吐为快。

互联网产品

最深刻的印象莫过于：可用性大于一切(允许局部瑕疵，但要保证可见功能快且稳)。

每个环节都值得去思考

打开App或输入网址访问你的网站（这是多么重要）
用户接入互联网，穿过层层路由终于到了目的地:入口接入（怎好意思怠慢）
入口机将其请求转发到应用服务集群（该你们表演了）
优先在缓存中获取数据（命中率），或者先去DB中快速读取(DB设计)到缓存并响应
原路返回(用户请求的数据)

整个过程一般要保证在200ms以内

接入层

负载均衡如域名多A，七层交换

这个地方除了负载均衡之外，比较好的做法：客户端主动获取一组ip（由server端分析来源地址应该优先返回哪几组IP）。为何？移动互联网下的dns劫持，不容小觑。

业务应用逻辑

业务应用，拆分、拆分、再拆分。

普遍都是水平集群(aws的经常会说应用scale out).

不是新鲜事物，只是最近国内社区大家都在谈论而已。新浪前两年就分享了他们的单元化架构思路。架构没有完美的，适合自己产品的业务，并且可以hold住，这个是很重要的。—— 恰如其分的架构(成本，效果，可控等) 往往令人称道

异步MQ

MQ的意义莫过于解耦和协调生产者和消费者。

##数据访问层

读写分离是常态，缓存高可用。

缓存与存储

存储

存储分为两块:分布式文件系统和传统的关系型数据库。针对第一块，小公司主要文件存储到第三方云存储吧。

然而，现在感觉，互联网产品的较量，何尝不是到处复制竞品。产品经理之过，还是小公司逐利性太强？大环境下小公司没有雄厚的资本积累，人才储备，做一个靠谱的产品。实则难矣，寡头垄断下，从基层做起，做大公司不想做的小领域，寻求突破。

#运维Ops

而今互联网产品运营与后台管理部分，基本上还是照传统软件的做法。好处是做给自己用，需求相对比较清晰。

后记

成长必须耐的住性子，给自己成长的时间，急功近利，误入歧途，收心!

罗马不是一天建成的

摘要