豆瓣广播

这年头的妹子都怎么了。条件比你差的你看不上,你看得上的条件比你好的别人不一定看得上你。你走心了以后发现别人条件比你差的你又反悔了,你走肾的被别人月抛了你又空虚寂寞冷了。突觉组里氛围也是tmd越来越诡异了.

百万级的微服务基础架构

其实这篇文章应该是五月份就已经进入了draft模式,年底梳理发现还有未完成的,所以应该今年事,今年毕。很多互联网的初创公司,一版融完了A轮或者进入B轮的时期,系统大多都是千疮百孔的,顶着快速增长的压力,码农们各种开始深夜修服务器。从万般紧凑的进度计划中,排列出治理的重构方案。发现痛点最多还是基础的用户和认证,其次是基础的接入层服务,之后再是运维管理平台。恰好也帮忙梳理过一些初创公司的痛,在此纪录下个人的一些心得体会。
初创的公司,场景大多要求,app,web,mobile都提供不同程度的服务,一般雄厚些的公司大多上来就以APP为主,android和ios并行前进,辅助以简单的web页面版本和mobile页面版本,再接入微信的导流,基本上就是一个初创公司所有的用户入口,偶然有一些特殊的B端定制化的pad之类要求,基础层不动,基本可以完全覆盖。
基础的服务设计,离不开原始的概念设计图,所有的设计,也都离不开业务的需求场景。所以任何抛开了基础业务场景的设计,都是在耍流氓,以下是以如上的概念场景,来进行的设计。基本的思路很简单,拆离基础的公有服务,做成微服务,以RESTFUL的接口互相交互,并且所有服务之间无状态,可以几乎各自独立的进行水平扩展。
原来玩MS体系技术的时候,画图基本上都是要求五图并出的,并且需要各自呼应,不能有缺失和矛盾,从不同的层面去阐述系统的整体设计思路,便于后期的细化。可惜创业公司大多飞奔前进,先于设计出代码,或者说完全由主负责通过自己的代码和经验去控制设计,高手固然可行,可惜高手少之又少,团队协作需要沟通理解的东西多之又多,于是各种先上,再补,再说的情况不绝。资本推动固然快准狠,不过欠下的债始终是要还的,至于什么时候还,呵呵,ceo大多说等这轮完了。
快速成长的互联网公司基本是不会留出独立的时间给技术团队进行架构的梳理和重构的,于是时间只能从各个feature当中来挤,码农基本通过加班来搞定,最为头疼的问题就是挤的过程当中的前后兼容,不过路总是人走出来的,大量的兼容代码在迭代的过程当中不绝于眼。再恶劣的环境一般也都能解,所以高手一般都是留有注释的,方便以后修,代码治理最好的套路也就是如此了。
简要的One Page Design可以快速的协调开发组对整体技术套路的理解,让大家朝着统一的方向前进,其实可以不用写的很复杂,能够让大家快速的的保持一致,才是关键。
arch1
系统概念设计图说明
 核心内容将通过triple store进行数据存储,并且依据自定义的规则生成对应的内容,进入业务数据库,供平台使用
 数据来源主要通过传感设备以及移动设备采集,经过数据筛选和数据加工,进入临时的内容数据库,平台依据规则有选择的进行MQTT标准化,存储至triple Store
 核心业务层平台主要负责处理复杂的业务逻辑,并且提供对应的流程和job的调度处理。
 业务平台将采用NODEJS进行构建,并且采用三端合一的Restful进行实现,方便终端各级的接入。
arch2
系统层次图设计说明
 终端用户目前需要支持移动端,微信,移动站点和PC站点的全面覆盖。
 核心的API层主要由RESTFUL框架进行封装,核心语言采用NODEJS,框架采用目前比较成熟的Express
 认证采用目前BEARER TOKEN的OAuth认证,并且采用统一的中间件在各个系统里面通过middleware进行快速集成
 业务流程和队列系统采用云平台进行设计和实现,对复杂业务的加工,统一经由队列消费worker进行处理。
 中间系统需要接入互联网基础的运维平台,持续集成平台,运营数据分析平台
 后部triple store的数据规则控制,数据分析采用标准的JENA协议。
arch3
物理结构图设计说明
 系统目前提供互联网接入的口径为pc端,移动端,以及微信客户端,后期会陆续加入app端的内容。
 接入主要提供主站和移动站。
 内部系统避免多个单点故障出现,所有的服务节点均采用负载多点方式
 后部业务数据库采用k/v和关系型数据库混合的模式,k/v采用目前较为成熟的MONGODB产品,主从心跳线三机热备切换模式,关系型采用MYSQL一主三从读写分离模式。
 Triple Store 产品采用你想要的任意
arch4
系统依赖图设计说明
 对于数据统计和分析,在app上线依赖目前主要的UMENG平台,
 对于微信端的账号绑定验证,需要依赖短信网关供应商
 平台部分的需要依赖cdn对js,css,图片等资源做加速
 对用户页面停留时间,pv,uv的统计,以及后期的搜索引擎优化,需要接入百度以及google的API
 内容处理队列采用云端产品。

互联网入门三套车

话说央妈都开始推互联网了,于是资本,人员等各种资源开始疯狂的涌入。但从一个技术民工的角度来看,涌入进来的弄局者,讨论到最后的结果基本都是,我们只差一个码农写码了。但是真正的互联网是怎么玩儿的,局外人们也只是看着互联网企业的惊人成长速度而管窥狸豹而已。其实真正能认识,并且相信套体系的boss应该没几个,尤其是想转型的传统企业,尤为困难,并不是简单的买一堆服务器,养几个死贵的码农那么简单的事情。于是有着各种大互联网公司的从业人员们一时洛阳纸贵。原来的各种行业的人才也开始涌入这个领域开始折腾,于是各种bat的墙角变成了市场上的香饽饽。阿猫阿狗齐上阵的时代开始到来。
互联网企业,所依赖的快速迭代,快速响应,一切以用户需求为主旨的背后,不可离开的线上三大体系,目前的巨头们,基本都是体系成熟,并且开始玩四个体系的细分领域和外延部分了。
1,运维监控体系
2,内容运营体系
3,数据化营销体系
4,持续迭代发布体系
所以衡量一个互联网公司估值价值的指标,从技术数据层面,依赖于这三个体系的正常运转,不过许多大boss可能第一次见投资人还基本对一些衡量的指标保持懵逼的状态。或者说保持一个不关注的状态,不过不同的领域也许依赖和衡量的指标貌似不尽相同,从技术角度来说,基本如下:
1,日活,用户量
2,次日留存,月留存
3,qps,tps
4,交易量,流水量
那对于各个体系,是如何去影响这些指标和辅助强化这些指标的呢?大致粗浅的理解如下:
运维监控体系:这个体系实际上是从前到后的一套完整的对线上服务器硬件,以及业务关键程序运行的健康度的监控,所以说得从两个维度来看这个东西。
系统角度:对于每天看着服务器的运维工程师来说,大规模的集群,基本上都采用了统一化的管理,linux上面对于集成部署和监控,有很多开源的组件,目前我们用的比较多的是salt和ansible,基本可以conver大部分的集成化运作指令,设想,一百台级别的服务器,需要随时发布,更新,以及监控各个服务器的cpu,内存,硬盘的占用情况。shell利器不可不用。现在云化的时代,对服务器的cpu,等硬件设备的监控大多云平台都带,几乎也都好使,不够的可以用云平台的接口做一个嘛。
业务程序角度:对于业务这块的运维监控,会比系统的要复杂得多,各个服务集群之间,所关注的业务点都不一样,为服务器化的集群,最主要的还是看http的响应数量和响应时间,这块我们大致会采用开源falcon来进行定制,分服务,分api,分页面来进行关键性的监控。例如,我们比较关注用户的注册量或者报名量,那么我们必然监控注册和报名的页面或者api的的请求量。单独出一个较为独立的图表。
内容运营体系:这个体系实际上决定了很多大多数终端用户看到的东西,比如说今天做个活动,明天做个活动,今天花式发个卷什么的,所以大多的内容运营平台几乎也都是按照系统的场景来定制化开发的,内容需要能够每天秒更新自己的活动和创意,而系统也必须秒支持。我记得有个典故,我们pm说这是一个cms,然后又加需求说这个东西其实是一个带crm的cms,然后这又是一个运维管理后台还要有审核等流程的机制,然后开发组就狂暴了,你们要的到底是尖椒炒肉,还是鱼香肉丝。所以从一个侧面说明这块东西的复杂程度。
数据化营销体系:这就是大家传说中的大数据了,不过大多数公司的数据都不能称为大数据吧,不过这块由于数据量巨大,还是需要一些大数据的基础基础来支持的。很多时候pm上了一个新feature,市场做了一个新活动,想要知道效果,比如和交易量相关的指标上升了,pm也得说出个理由来。或者说,用来说服码农全天秒出新feature的理由,也是由这些数据来支撑的。
例如,pm和dev leader死磕,说这个东西上了没什么卵用,于是乎pm说到时候我拿数据和你说话,dev leader于是带着项目组周日加班干出来这个新feature,上线了,然后跑了一个星期,然后告诉开发组,你看,我们的这个新feature导致我们的app访问时常增长了10%,dev于是哑口无言,开发们也乐得屁颠屁颠的,俺们写的东西终于是有用的啊,于是乎下一个feature继续接踵而至。当然,也有pm被打脸的时候,基本上就是pm买瓜子买水,捏背,请吃饭的节奏。
这些报表的基础数据,就来源于数据化营销的基础平台数据。初期落地到系统当中的大多就是日志和关键点的埋点数据。重要页面的action几乎都需要埋点,日志请求基本也都是全记录的。一天动辄上几十个个T的数据,大多都用hadoop家族系列产品。到了后期的数据分析组,技术就会用得比较复杂,大多都是混合型的技术架构,而且还有复杂的数据专家坐镇,直接影响领导层的战略调整。记得有个女同学做这个的叫什么来着,大家都叫她“统计学之母”。
持续迭代体系:很多人一看这个就会说,不就是一个jenkins和gitlab-ci这样一些产品嘛,但是貌似具体落地起来并不是一个持续化集成体系能搞定的事情,快速的迭代,需要PM(项目经理和产品经理目前互联网公司是复合型的,如果在你的公司的这两个角色不是复合型的,那么只能呵呵了)非常清晰的了解每个阶段需要快速实现的功能,不要问为疯狂的pm为啥老加班,他们需要控制整个产品的内容,feature上线的时间,开发资源的调配,市场的反馈,数据分析模型的建立,以达到最快的速度响应客户的需求,做到快速的调整。这个内容之所以是一套系统,在于它就是一个企业快速更新的基础。几乎涉及到整条业务线的调整优化。所以牛x的pm一个迭代周期基本是1-2周,而落地到具体的内容,就是码农的代码写完,测试,发布到线上,并且周知相关的各种人员。jenkins在具体的落地的过程当中可以扮演很多关键的角色,如包的自动化测试,编译,灰度的发布。极大的简化运维人员的工作负担。但是对于超大的交叉型互相依赖的线上项目,一个jk估计就没法满足需求了,具体的可以看下阿里发布的云端持续化发布平台,感觉屌屌的,几乎也是一套复合型的框架,不过不一定能够满足你们公司的场景。
以上就是把原来一些粗浅的理解和内容写个心得记录下来,仔细琢磨其实很多点如果深入进去去研究,估计都可以写成一小本小册子了,配点图在配点实战的操作步骤,几乎就可以出一本书了。不过大部分的文字,几乎很难传达个人理解的真实的内容,因为每个人的理解可能都是不一样的,因为大脑的思维方式不一样,不一定能get到你的点。所以相对而言,还是落地的代码和搭建好的系统相对便于容易沟通一些。
是马是骡子,自己搭建一套跑起来,并且让大家都用起来,应该就知道了。

豆瓣广播

新的一代更加自我和无所畏惧,所以从某种程度上来说是社会进步了,生产力提高了,人民的安全感增加了,但是我们这一波人却不是这么认为的。

豆瓣广播

土豪不知道,我定义叔标准不高,是按照组里女生预期均值,月2万算的。所以要按照这个标准基本年收入50万以上才能负担得起吧!
————————–
算了下,尼玛好歹也应该是税后50,哦哈哈哈。