Category Archives: Web

微信小程序开发资源汇总

QQ交流群

目录

推荐

置顶

官方文档

工具

  • WePY ★12k+ – 支持组件化的小程序开发框架
  • mpvue ★11k+ – 基于 Vue.js 的小程序开发框架,从底层支持 Vue.js 语法和构建工具体系
  • Taro ★3.9k – 使用 React 的方式开发小程序的框架,同时支持生成多端应用
  • Labrador ★1.5k – 支持 ES6/7 的微信小程序组件化开发框架
  • wept ★1.8k – 微信小程序实时运行环境
  • wafer ★1.6k – 快速构建具备弹性能力的微信小程序
  • wechat_web_devtools ★600+ – Linux 下微信开发者工具
  • minapp ★400+ – TypeScript 版小程序开发框架(兼容原生小程序代码)
  • tina ★300+ – 轻巧的渐进式微信小程序框架
  • xpmjs ★100+ – 微信小程序云端增强 SDK
  • WeApp-Workflow ★100+ – 基于 Gulp 的微信小程序前端开发工作流
  • gulp-wxa-copy-npm – 微信小程序 gulp 插件,解决 npm 包管理和 babel-runtime
  • weact – 用 JSX 快速开发小程序
  • socket.io-mp-client – 微信小程序 socket.io 客户端
  • wxa – 方便的小程序开发框架
  • px2rpx – Px 转 Rpx 在线工具
  • wxml-parser – JavaScript WXML parser
  • weappx – 基于 redux 的数据层管理框架
  • weapp-start – 基于插件机制的开发脚手架,改善原生小程序开发体验
  • Egret Wing – 支持微信小程序实时预览的 IDE
  • wxapp-graphql – 小程序GraphQL客户端

插件

教程

视频教程

文章

组件

Demo

from:https://github.com/justjavac/awesome-wechat-weapp

中国互联网20年简史(1998-2018),告诉你本质是什么、规律是什么

我先说说互联网三大支柱:

1、内容:新闻&文学、音乐&视频

2、社区+内容

3、游戏

4、电子商务

我们来简单回顾一下中国互联网20年。咱们先从1998年开始。

一、1998年:内容门户元年

1998年2月,张朝阳正式成立搜狐。给中国产业带来了VC风险投资、CXO职业经理人团队,让中国老百姓认知了中国互联网。

1998年,四通利方和北美华人网华渊网合并,成立新浪网。给中国产业带来了并购、创始人被踢出团队。

1997年,网易成立。1998年推出网易免费电子邮件服务。

显然,这是内容门户之年。

虽然1998年腾讯也成立了,但显然大家都没注意到它。但最后四大门户是:搜狐、新浪、网易、腾讯。

还有一家公司成立,那就是在线网络游戏公司:联众,出自希望公司UCDOS软件团队。

你看,内容门户+BBS论坛社区+IM+游戏,在20年前,就同时出现了。中国互联网主航道,都基本出现。

二、1999年:电子商务元年

内容门户大热到极点。连联想都做了一个FM365。更别说还有中华网、TOM网、多来米这些富家子弟玩的。这些显然都是后知后觉了。

1999年11月,当当B2C成立,标品卖书,客单价也低,正好做启蒙。1999年,阿里巴巴B2B也成立了,搞黄页,帮助中国小商品制造出口走向国际。

1999年还成立了一家当时没人知道的公司:携程。

1999年还成立了一家公司:51job,网上找工作。其实招聘的本质是:黄页信息,只不过这个黄页不是企业信息,而是个人简历信息。

这是中国电子商务的开始。他们真是先知先觉。

三、2000年:内容门户上市年

网易、搜狐、新浪都在纳斯达克上市。这才短短3年时间。

2000年1月,百度成立。

四、2001年:移动手机元年

美国互联网投资泡沫破裂,也影响了中国。很多后来进入者都纷纷转型去开发企业软件,因为他们熟悉互联网、熟悉当时火热的Web开发技术和JAVA开发技术,所以他们一开始就做供应链互联网平台。当时中国企业软件商还在纷纷用VB/PB/DELPHI开发局域网企业内部管理软件呢。

但是在前几年互联网资本的推动下,基础设施:通信&数据传输网络也在迅猛发展。诺基亚在这一年市值逼近2500亿美金,中国出现国产手机热,以波导为代表,IT厂商联想也介入进来,家电厂商海尔也介入,电话座机厂商步步高(Vivo和Oppo的母公司)也介入。

五、2002年:移动手机内容SP元年

2002年,中国移动和中国联通的手机终于能短信互通了。好不容易2000年上市的三大门户都熬的受不了,想寻找到立刻变现的业务。

彩铃、短信报热。网易首先抓住这个机遇(嘿嘿,大家可以另外寻找网易和张静君和广州电信局的渊源)。中国互联网企业做SP业务开始了,尤其是把网上的新闻和段子通过短信传播。

六、2003年:网络游戏元年

2003年7月,盛大公司发布传奇世界游戏,引发了中国网络游戏热。随后,九城、完美时空、巨人等等公司跟进,造就了中国很多赚的盆满钵满的网络游戏公司。这个行当也给中国积累了大量的产品经理、制作人、美工人才、音效人才、3D技术、网络技术。

七、2004年:中国互联网第一波集中上市收割年

2004年,移动手机内容SP厂商:空中网、掌上灵通网,上市。

2004年,垂直金融内容门户公司:金融界,上市

2004年,社区+IM+游戏厂商腾讯上市。

2003年12月(相当于2004年了吧),中国电子商务第一个公司:携程,上市。携程。从1999年中国电子商务开始元年,到2003年,这才短短4年时间。

2004年,泛电商人才招聘网:51job上市。

2004年,网上卖机票电商网:E龙上市。

2004年,网络游戏厂商:盛大,上市。

从1998年算来,到2004年,6年时间,中国互联网开始了第一波收割热潮。

八、2005年:Web2.0社区内容元年

2005年,超女最火的一届出现:李宇春、张靓颖、何洁。大众用短信投票引爆全国。这是民众的、互动的狂欢。

2005年,新浪博客发布。

2005年3月,豆瓣成立。这是一个点评的网站。

2005年12月,58同城成立,这是一个个人黄页发布的网站。

额外,搜索引擎公司:百度,在这一年上市了。

七、2006年:网络视频内容元年

2006年,六间房视频网成立。2006年,李善友的酷六网成立。2006年,优酷网成立。2006年,Google并购Youtube网。

另外,2005年4月,土豆网成立。2005年,迅雷公司正式成立。2005年,VeryCD(电驴下载)公司正式成立。这都是和视频电影的崛起有关联的。

过去大家只能看文字图片内容网站,做图片钻展广告。现在有了更直观的视频网站,而且每部电影都可以贴片做广告了。

但是并不代表文字内容网站失落,相反,中国网络文学崛起,你看:2006年,天下霸唱开始写鬼吹灯引爆盗墓类小说、2006年当年明月开始写明朝那些事儿引爆写史类小说,2006年月关开始写回到明朝当王爷引爆穿越类小说。

2006年,其实还有一个大混战,就是楼宇广告大战。成立于2003年的分众传媒,2005年上市,2006年并购了聚众传媒、框架传媒。

八、2007年:电子商务高速成长年

2007年,阿里巴巴B2B业务在香港上市。

但是大家也别忘了,2007年8月,中关村一个经营了快10年的拥有11家线下店铺IT硬件批发零售商,融了一笔钱,开始关闭自己的线下店,专注高速发展线上电商自营零售,那就是京东。

2007年,Yes!PPG成立,主打自创品牌的男士商务休闲服装。2007年,模仿Yes!PPG的凡客诚品也成立了。这是中国自创品牌的电子商务公司,集:研发设计、供应链采购、委托加工、质量控制、商品电商零售、仓储物流配送于一体。

2007年,也是中国快捷酒店大战的一年。如家、汉庭、锦江之星、7天、莫泰、格林豪泰、布丁、桔子酒店…,好多好多。

悄悄另外说一句:2007年,iPhone上市了,大内存、高速CPU、高速WIFI网络、大屏幕、多点触摸输入操作,这几乎是和过去的智能手机有天壤差别:小内存、小屏幕、GPRS联网、笔触输入或键盘输入。中国移动互联网暗示着要大规模爆发了。

九、2008年:智能手机元年

2008年,是中国互联网的十周年。但是这一年也暗示着,中国PC Web互联网即将开始走向最高峰,最高峰也意味着下一个时代已经在悄然启动。

2008年,Google正式发行Android操作系统。

2008年,Apple发布iPhone3G手机,最最关键的是,智能手机的高利润盈利模式、流量口模式出现了:App Store。想想百度收购91,其实也想占领智能移动互联网的入口,没想到独立的应用商店根本不存在活路,全被智能手机厂商在底层釜底抽薪了,人家有小米应用商店、华为应用商店…,全是硬件+软件一体化的。

2008年,山寨手机热啊。在联发科一体化MTK模组的支持下,在华强北电子零件集散批发、深圳电子代工场云集的支撑下,中国人制造手机的门槛被放到最低。

十、2009年:交战年

2009年,新浪微博发布显然是最显眼的。随后,各大内容门户网站纷纷发布类微博产品服务。微博,120个字,类似短信使用体验却可以带图片(比短信好),可以关注名人还可以评论互动(不像QQ得双向关注),也可以随手转发。

除了微博这种类互联网手机上的多媒体短信产品大战,这一年整个互联网界都不平静。

淘宝发布购物搜索,屏蔽百度爬虫。当然,微软也发布了Bing搜索引擎来PKGoogle搜索引擎。

腾讯和搜狗针对输入法进行诉讼。因为输入法在用户需求探知、弹窗引流、输入汉字导流方面具有很高的入口杀伤力。

网络游戏《魔兽》的代理运营权,也在九城、网易之间拉锯。

还有2008年很火的基于QQ社交网络关系的页游:偷菜,开心网和千橡开心网也进行了诉讼。

为什么2009年如此不平静?就是因为PC Web互联网进入成熟期,产业要开始高度集中,要进行整合,不可避免要咔咔作响。

2009年,中国三大运营商均获得3G牌照,移动互联网眼看着眼看着要来临了。

十一、2010:电商爆发年

2010年大家最记忆犹新的肯定是百团大战,大量团购网站出现,尤其以2010年3月美团成立为标志。中国电子商务:衣食住行,衣,有淘宝;食开始了,就是这些团购网;住,有曾经的如家快捷酒店大战,也有58的租房二手房黄页广告聚焦房产行业大战;行,有过去的携程、E龙、同程、去哪儿大战。除了衣是实物零售业外,其他食住行都是服务电商业,即:在网上吸引消费者流量,在网上获得优惠折扣,在网上下订单,甚至在网上进行支付,然后在线下进行到场消费。

2010年,在衣这个事情上,还有一个轰动的事,那就是淘宝双十一热。但这已经其实是第二届了(第一届是2009年双11),但就如超女一样,也是第一届举办完了大部分人都不知道,第二届才引爆。双11对于淘宝的意义非常大。而京东,在2010年也迎来了爆发式增长:开放POP平台、一线城市极速达、收购网银在线介入金融业务。而且京东主动发起了图书大战,直指当当老大哥(当当可谓是中国互联网最早的电商零售)。还有一家发源于手册邮寄购买最终爆发于电商的服装零售公司:麦考林,也在2010年上市了,成为了第一家上市的电子商务零售公司(2007年阿里巴巴B2B业务上市。)

1999年,中国电商元年;2007年,中国电商成长年;2010年,中国电商爆发年。

当然,在PCWeb纯互联网领域,2010年也发生了一件非常大的事情,就好像两个黑洞碰撞一样巅峰对决,那就是3Q大战。2010年11月21日,在工信部、网信办的协调下,两个公司达成和解,不互相封杀卸载对方的软件。中国PC 互联网终于走到了尽头。就好像红巨星要爆炸要产生超新星是一样一样的。从1998年开始的PC Web互联网,走到了2008年智能手机元年,2009年互联网产业整合交战,最终在2010年3Q大战最高巅峰对决中收场。

再想想中国移动互联网,2008年是智能手机元年,今年是2018年,也十年了,今年的大战是腾讯集团和今日头条的大战。相信到2020年,也会如超新星一样,那时候是什么互联网呢?已经有了ADSL宽带PC Web 互联网和4G 移动 App互联网,难道那时候在5G的引导下,会出现万物互联网?

4G移动App互联网,以移动智能手机为主产业,那5G万物互联网,什么是主产产业呢?难道是智能汽车?

十二、2011:中国移动互联网元年

这一年,有两个重要级产品出现,一个是智能手机:小米和MIUI OS出现,一个是原生移动IM:微信出现。

智能手机硬件、Andriod操作系统、应用商店、IM通信,这种组合层次颇值得人寻味。在万物互联网时代会不会出现的最初超级应用也是这样?

其实早在2G GPRS时代,在2008年,手机QQ已经很多人使用了,但是微信出现了,手机QQ没落了。微信的出现正好和iPhone成为智能手机事实标准是同步的。从iPhone开始,过去手机是五花八门各种样子各种功能,尤其在山寨手机之时到达最高潮,然后在iPhone带动下,全世界的手机都变成一模一样的大体模样了。也就是说,都是大屏幕、无键盘。微信的崛起第一步就是:语音消息、手机通讯录导入、摇一摇周边。你看,全是原生应用了手机的独特特性。大家在思考万物互联网的时候也应该这样思考,要充分应用硬件的独特特性,而不是把大象装在冰箱里(比如很多人把企业管理软件精简功能做成App)。

十三、2012年:中国移动互联网发展年

这一年,中国手机网民数量超过了电脑上网网民数量(其实2013年中国政府才要求运营商强力推4G)。

这一年,中国移动互联网高速发展,大家都纷纷把自己的PC Web互联网的功能翻新成App版本。

华为、锤子也正式宣布进入智能手机领域。360和海尔也联合推出超级战舰手机。就连腾讯也谨慎的做了一个手机ROM。大家纷纷想从智能手机硬件、智能路由器和DNS、OS、应用商店、通信IM超级APP,一层层地釜底抽薪。

十四、2013:中国移动互联网爆炸年

3年啊,同志们。太快了,怪不得劳模雷军说:现在就连睡觉都觉得是浪费。

这一年,小米开始构建自己的智能产品生态,发布了好几款智能产品。这一年,乐视智能电视发布,乐视开始引爆江湖。

在这一年有两个关键事件决定了这一年是移动互联网爆炸年。一个是微信发布了游戏流量入口、打飞机小游戏狂潮掀起了移动游戏App的热潮。移动互联网,怎么能够少了游戏这一个半边天呢。微信在这一年还发布了公众号。没有媒体人的卷入,就不可能有大影响力大声音。微信也是在这一年狂发展的。

另外一个大事件就是,也就是从这一年开始,BAT们都开始做好自己的主流超级流量App,大力发展Open API开放平台,大力做投资并购。中国移动互联网为什么发展的这么快,关键就是有三大要素:超级流量、Open API和平台、资本投资和并购进入山头帮派时代。同志们,这句话要标红啊。这是过去中国互联网界从未有过的事情啊。这是中国互联网的并购年,其中最大的收购案就是百度以18.5亿美金收购91无线。

十五、2014:中国企业服务元年

在这一年,中国电商出现了一件大事:京东、阿里纷纷上市。京东和阿里占据中国线上B2C零售80%市场份额,构成了真正的双子星结构。这种市场结构,意味着这个市场已经成为寡头市场。现在再进入这个市场,不可能再出现第三巨头了,从第三名到最后一名,所有加总才能占据最多20%市场。从目前来看,就连拼多多这种拼团模式、云集微店众包销售模式,也只能成诸侯而不能成王。

虽然说,云计算创业三小龙:Ucloud、七牛、青云,都是2010-2011间成立的。但是,中国企业服务投资规模第一波热潮却真正来自2014年。其实不说2006年Amazon发布AWS,就说阿里云,也是在2009年10月写下第一行代码,2012年做天猫聚石塔项目,2013年换帅胡晓明开始高速发展。而中国IaaS云计算的高潮,还要等到2016年,那一年,所有互联网大佬、所有中国系统集成商大佬都已经进入IaaS公有云和私有云的市场。不过很多人却还后知后觉,直到2015年中国企业服务投资最高潮,很多人才匆忙杀入了这个行业,才匆忙升级要做SaaS软件。

这一年还有件事,就是菜鸟网络在这年成立了。菜鸟网络不搞仓库不买卡车不跑运输不招业务人员,但是菜鸟网络凭借淘宝天猫的订单流量、凭借自己的大数据建模技术,来做到智能的仓储物流调度,抽取中间的调度佣金。这本质上是电商+企业服务的混合体。

这一年还有件事,是滴滴的快速崛起。滴滴后来被人们笑话段子都演变成了滴滴模式(拼多多拼团也是种模式、团购秒杀倒计时也是种模式),什么滴滴打人、滴滴代喝、滴滴代嫁等等,哈哈哈。但是,滴滴代驾、滴滴拼车业务真的出现了。滴滴的核心是:根据地理位置(智能手机独特特性)、根据业务大数据和用户画像,智能匹配最合适的打车人和出租车,抽取中间的调度佣金。这本质也是电商+企业服务的混合体。

也就是说,智能调度匹配抽佣金,这个模式,会在中国业务+IT服务的各行各业中,都会形成落地的业务场景。这就是一种经过验证的以技术为本的商业模式。这个模式,非常值得中国企业服务商去探索借鉴思考。

十六、2015:中国互联网金融元年

这一年,在中央的大众创业万众创新的推动下,互联网金融开始热潮。当然,中国电子商务要高速发展,没有金融的支撑也是不能更快更大的发展。

所以这一年,P2P热、众筹热、消费贷热、供应链金融热都起来了。

但更突出的是:微信支付和支付宝支付开始大战。大家纷纷通过各种扫街、发起补贴活动,到处贴二维码,可以扫码支付。现在,就连买菜买鸡蛋夹肉饼,都可以用手机扫码。这种便捷性是全世界最领先的。

十七、2016年:智能元年

这一年,直播热崛起。但是这种直播和过去最早YY的直播还不一样。现在的直播最关键应用了实时美颜技术、虚拟AR技术。

这一年,从支付宝AR找福字、美颜App自带兔子耳朵虚拟表情开始,就发现今年的不一样了。那就是现实和虚拟的实时结合。

所以这一年,也带动了AR、VR设备热。也带动了人工智能技术热,先从人脸识别开始。

直播热从娱乐很快扩展到了电商,从虚拟送礼盈利走向推荐商品带货盈利。这也造就了2016年的微商热。这不同于过去的微商拼命加5000人拼命加群拼命发朋友圈鸡汤发微商广告的模式。这一年的微商都在实时美颜直播技术中统统成为了网红。

直播打赏热(这里也有上一年移动支付大战红包大战的功劳),也渐渐带动了另外一个正经事:知识网红(如罗振宇)+知识付费(如得到)。

这一年,还出现了共享单车大战,最后连颜色都不够用了。这里面最有名的论战就是马化腾和朱啸虎的言战,焦点是谁能笑到最后。马化腾认为是一定要是智能设备,如智能车锁,这显然是技术派的看法。而朱啸虎代表运营派,也就是说:最成熟的产品和消费习惯,最广阔的市场,用资本轰开。现在,朱啸虎的OfO陷入尴尬境地,朱啸虎后来都暗示服了软,显然,智能才是核心。

十八、2017年:新零售元年

2017年说什么热,那必须是新零售。新零售的本质是用智能传感设备、人工智能技术,实现线下数据收集和线上电商是一样的效果。大家切记切记。

虽然说,有人把新零售看做是线下,用正规企业运营方法再重做一次,就如同当年如家他们用资本+企业标准运营管理方法重塑中国快捷酒店业一样。

技术派:无人零售商店、无人货架&货柜、智能购物车、智能称重台、人脸识别进门、人脸识别自动支付

运营派:生鲜、生鲜+餐饮堂食、连锁便利店、中央厨房供应链….

十九、2018年:

2018年,中国互联网金融热已经过去了3年。今年卷土重来的是:区块链。创建X币项目、发币上交易所市,成了主流割韭菜模式。看不清看不清。

在去年直播热、直播技术、直播打赏普及成熟的基础上,快手、抖音短视频热崛起。但是这种短视频又和过去的移动视频热不一样。因为除了技术流畅、打赏付费习惯成熟外,现在抖音又多了附近、朋友、互动。这简直是下一代社交网络的潜力啊。怪不得腾讯今天上半年从收购到打击抖音到内部赛马做了N多短视频App,根源就在于此。

我过去就说过,QQ发源于台式机拨号上网文字时代,微信发源于智能手机4G上网语音时代,那么下一代社交网络工具一定是基于万物互联5G上网视频时代。

从2008年智能手机元年开始算起,今年也已经十年了。智能手机移动互联网时代也要高潮地结束了。今年,小米也要在港交所上市了。

一个时代即将结束(还有2年最后的两个黑洞大碰撞,我猜是腾讯集团和今日头条集团),那么我们在今年,确实应该多静下来思考思考,几个好友坐下来重新回归历史一片空白该想想了、放开脑洞发散性讨论讨论了。

下一代主流硬件是什么?下一代主流OS是什么?

下一代主流社交网络工具是什么?下一代搜索是什么(是视觉识别和语音交互吗)?

下一代内容是什么样子的?比如说新闻、文学、视频、音乐…。

下一代游戏是什么样子的(是ARVR吗)?

下一代电子商务是什么样子的?下一代后端企业服务是什么样子的?

这里边,有你吗?

下一代商业模式的核心要素是什么?除了:流量、资本、技术和数据以及开放平台外,还有什么新的要素?

from:https://mp.weixin.qq.com/s/X195WPlHz6IyMyg-lpc9Yg

微服务化之缓存的设计

本文章为《互联网高并发微服务化架构实践》系列课程的第五篇

前四篇为:

微服务化的基石——持续集成

微服务的接入层设计与动静资源隔离

微服务化的数据库设计与读写分离

微服务化之无状态化与容器化

在高并发场景下,需要通过缓存来减少数据库的压力,使得大量的访问进来能够命中缓存,只有少量的需要到数据库层。由于缓存基于内存,可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计,缓存的设计时必不可少的一环。

一、为什么要使用缓存

为什么要使用缓存呢?源于人类的一个梦想,就是多快好省的建设社会主义。

多快好省?很多客户都这么要求,但是作为具体做技术的你,当然知道,好就不能快,多就没法省。

可是没办法,客户都这样要求:

这个能不能便宜一点,你咋这么贵呀,你看人家都很便宜的。(您好,这种打折的房间比较靠里,是不能面向大海的)

你们的性能怎么这么差啊,用你这个系统跑的这么慢,你看人家广告中说速度能达到多少多少。(您好,你如果买一个顶配的,我们也是有这种性能的)

你们服务不行啊,你就不能彬彬有礼,穿着整齐,送点水果瓜子啥的?(您好,我们兰州拉面馆没有这项服务,可以去对面的俏江南看一下)

这么贵的菜,一盘就这么一点点,都吃不饱,就不能上一大盘么。(您好,对面的兰州拉面10块钱一大碗)

怎么办呢?劳动人民还是很有智慧的,就是聚焦核心需求,让最最核心的部分享用好和快,而非核心的部门就多和省就可以了。

你可以大部分时间住在公司旁边的出租屋里面,但是出去度假的一个星期,选一个面朝大海,春暖花开的五星级酒店。

你可以大部分时间都挤地铁,挤公交,跋涉2个小时从北五环到南五环,但是有急事的时候,你可以打车,想旅游的时候,可以租车。

你可以大部分时间都吃普通的餐馆,而朋友来了,就去高级饭店里面搓一顿。

在计算机世界也是这样样子的,如图所示。

越是快的设备,存储量越小,越贵,而越是慢的设备,存储量越大,越便宜。

对于一家电商来讲,我们既希望存储越来越多的数据,因为数据将来就是资产,就是财富,只有有了数据,我们才知道用户需要什么,同时又希望当我想访问这些数据的时候,能够快速的得到,双十一拼的就是速度和用户体验,要让用户有流畅的感觉。

所以我们要讲大量的数据都保存下来,放在便宜的存储里面,同时将经常访问的,放在贵的,小的存储里面,当然贵的快的往往比较资源有限,因而不能长时间被某些数据长期霸占,所以要大家轮着用,所以叫缓存,也就是暂时存着。

二、都有哪些类型的缓存

当一个应用刚开始的时候,架构比较简单,往往就是一个Tomcat,后面跟着一个数据库。

简单的应用,并发量不大的时候,当然没有问题。

然而数据库相当于我们应用的中军大帐,是我们整个架构中最最关键的一部分,也是最不能挂,也最不能会被攻破的一部分,因而所有对数据库的访问都需要一道屏障来进行保护,常用的就是缓存。

我们以Tomcat为分界线,之外我们称为接入层,接入层当然应该有缓存,还有CDN,这个在这篇文章中有详细的描述,微服务的接入层设计与动静资源隔离

Tomcat之后,我们称为应用层,应用层也应该有缓存,这是我们这一节讨论的重点。

最简单的方式就是Tomcat里面有一层缓存,常称为本地缓存LocalCache。

这类的缓存常见的有Ehcache和Guava Cache,由于这类缓存在Tomcat本地,因而访问速度是非常快的。

但是本地缓存有个比较大的缺点,就是缓存是放在JVM里面的,会面临Full GC的问题,一旦出现了FullGC,就会对应用的性能和相应时间产生影响,当然也可以尝试jemalloc的分配方式。

还有一种方式,就是在Tomcat和Mysql中间加了一层Cache,我们常称为分布式缓存。

分布式缓存常见的有Memcached和Redis,两者各有优缺点。

Memcached适合做简单的key-value存储,内存使用率比较高,而且由于是多核处理,对于比较大的数据,性能较好。

但是缺点也比较明显,Memcached严格来讲没有集群机制,横向扩展完全靠客户端来实现。另外Memcached无法持久化,一旦挂了数据就都丢失了,如果想实现高可用,也是需要客户端进行双写才可以。

所以可以看出Memcached真的是设计出来,简简单单为了做一个缓存的。

Redis的数据结构就丰富的多了,单线程的处理所有的请求,对于比较大的数据,性能稍微差一点。

Redis提供持久化的功能,包括RDB的全量持久化,或者AOF的增量持久化,从而使得Redis挂了,数据是有机会恢复的。

Redis提供成熟的主备同步,故障切换的功能,从而保证了高可用性。

所以很多地方管Redis称为内存数据库,因为他的一些特性已经有了数据库的影子。

这也是很多人愿意用Redis的原因,集合了缓存和数据库的优势,但是往往会滥用这些优势,从而忽略了架构层面的设计,使得Redis集群有很大的风险。

很多情况下,会将Redis当做数据库使用,开启持久化和主备同步机制,以为就可以高枕无忧了。

然而Redis的持久化机制,全量持久化则往往需要额外较大的内存,而在高并发场景下,内存本来就很紧张,如果造成swap,就会影响性能。增量持久化也涉及到写磁盘和fsync,也是会拖慢处理的速度,在平时还好,如果高并发场景下,仍然会影响吞吐量。

所以在架构设计角度,缓存就是缓存,要意识到数据会随时丢失的,要意识到缓存的存着的目的是拦截到数据库的请求。如果为了保证缓存的数据不丢失,从而影响了缓存的吞吐量,甚至稳定性,让缓存响应不过来,甚至挂掉,所有的请求击穿到数据库,就是更加严重的事情了。

如果非常需要进行持久化,可以考虑使用levelDB此类的,对于随机写入性能较好的key-value持久化存储,这样只有部分的确需要持久化的数据,才进行持久化,而非无论什么数据,通通往Redis里面扔,同时统一开启了持久化。

三、基于缓存的架构设计要点

所以基于缓存的设计:

1、多层次

这样某一层的缓存挂了,还有另一层可以撑着,等待缓存的修复,例如分布式缓存因为某种原因挂了,因为持久化的原因,同步机制的原因,内存过大的原因等,修复需要一段时间,在这段时间内,至少本地缓存可以抗一阵,不至于一下子就击穿数据库。而且对于特别特别热的数据,热到导致集中式的缓存处理不过来,网卡也被打满的情况,由于本地缓存不需要远程调用,也是分布在应用层的,可以缓解这种问题。

2、分场景

到底要解决什么问题,可以选择不同的缓存。是要存储大的无格式的数据,还是要存储小的有格式的数据,还是要存储一定需要持久化的数据。具体的场景下一节详细谈。

3、要分片

使得每一个缓存实例都不大,但是实例数目比较多,这样一方面可以实现负载均衡,防止单个实例称为瓶颈或者热点,另一方面如果一个实例挂了,影响面会小很多,高可用性大大增强。分片的机制可以在客户端实现,可以使用中间件实现,也可以使用Redis的Cluster的方式,分片的算法往往都是哈希取模,或者一致性哈希。

四、缓存的使用场景

当你的应用扛不住,知道要使用缓存了,应该怎么做呢?

场景1:和数据库中的数据结构保持一致,原样缓存

这种场景是最常见的场景,也是很多架构使用缓存的适合,最先涉及到的场景。

基本就是数据库里面啥样,我缓存也啥样,数据库里面有商品信息,缓存里面也放商品信息,唯一不同的是,数据库里面是全量的商品信息,缓存里面是最热的商品信息。

每当应用要查询商品信息的时候,先查缓存,缓存没有就查数据库,查出来的结果放入缓存,从而下次就查到了。

这个是缓存最最经典的更新流程。这种方式简单,直观,很多缓存的库都默认支持这种方式。

场景2:列表排序分页场景的缓存

有时候我们需要获得一些列表数据,并对这些数据进行排序和分页。

例如我们想获取点赞最多的评论,或者最新的评论,然后列出来,一页一页的翻下去。

在这种情况下,缓存里面的数据结构和数据库里面完全不一样。

如果完全使用数据库进行实现,则按照某种条件将所有的行查询出来,然后按照某个字段进行排序,然后进行分页,一页一页的展示。

但是当数据量比较大的时候,这种方式往往成为瓶颈,首先涉及的数据库行数比较多,而且排序也是个很慢的活,尽管可能有索引,分页也是翻页到最后,越是慢。

在缓存里面,就没必要每行一个key了,而是可以使用Redis的列表方式进行存储,当然列表的长短是有限制的,肯定放不下数据库里面这么多,但是大家会发现其实对于所有的列表,用户往往没有耐心看个十页八页的,例如百度上搜个东西,也是有排序和分页的,但是你每次都往后翻了吗,每页就十条,就算是十页,或者一百页,也就一千条数据,如果保持ID的话,完全放的下。

如果已经排好序,放在Redis里面,那取出列表,翻页就非常快了。

可以后台有一个线程,异步的初始化和刷新缓存,在缓存里面保存一个时间戳,当有更新的时候,刷新时间戳,异步任务发现时间戳改变了,就刷新缓存。

场景3:计数缓存

计数对于数据库来讲,是一个非常繁重的工作,需要查询大量的行,最后得出计数的结论,当数据改变的时候,需要重新刷一遍,非常影响性能。

因此可以有一个计数服务,后端是一个缓存,将计数作为结果放在缓存里面,当数据有改变的时候,调用计数服务增加或者减少计数,而非通过异步数据库count来更新缓存。

计数服务可以使用Redis进行单个计数,或者hash表进行批量计数

场景4:重构维度缓存

有时候数据库里面保持的数据的维度是为了写入方便,而非为了查询方便的,然而同时查询过程,也需要处理高并发,因而需要为了查询方便,将数据重新以另一个维度存储一遍,或者说将多给数据库的内容聚合一下,再存储一遍,从而不用每次查询的时候都重新聚合,如果还是放在数据库,比较难维护,放在缓存就好一些。

例如一个商品的所有的帖子和帖子的用户,以及一个用户发表过的所有的帖子就是属于两个维度。

这需要写入一个维度的时候,同时异步通知,更新缓存中的另一个维度。

在这种场景下,数据量相对比较大,因而单纯用内存缓存memcached或者redis难以支撑,往往会选择使用levelDB进行存储,如果levelDB的性能跟不上,可以考虑在levelDB之前,再来一层memcached。

场景5:较大的详情内容数据缓存

对于评论的详情,或者帖子的详细内容,属于非结构化的,而且内容比较大,因而使用memcached比较好。

五、缓存三大矛盾问题

1、缓存实时性和一致性问题:当有了写入后咋办?

虽然使用了缓存,大家心里都有一个预期,就是实时性和一致性得不到完全的保证,毕竟数据保存了多份,数据库一份,缓存中一份,当数据库中因写入而产生了新的数据,往往缓存是不会和数据库操作放在一个事务里面的,如何将新的数据更新到缓存里面,什么时候更新到缓存里面,不同的策略不一样。

从用户体验角度,当然是越实时越好,用户体验越流畅,完全从这个角度出发,就应该有了写入,马上废弃缓存,触发一次数据库的读取,从而更新缓存。但是这和第三个问题,高并发就矛盾了,如果所有的都实时从数据库里面读取,高并发场景下,数据库往往受不了。

2、缓存的穿透问题:当没有读到咋办?

为什么会出现缓存读取不到的情况呢?

第一:可能读取的是冷数据,原来从来没有访问过,所以需要到数据库里面查询一下,然后放入缓存,再返回给客户。

第二:可能数据因为有了写入,被实时的从缓存中删除了,就如第一个问题中描述的那样,为了保证实时性,当数据库中的数据更新了之后,马上删除缓存中的数据,导致这个时候的读取读不到,需要到数据库里面查询后,放入缓存,再返回给客户。

第三:可能是缓存实效了,每个缓存数据都会有实效时间,过了一段时间没有被访问,就会失效,这个时候数据就访问不到了,需要访问数据库后,再放入缓存。

第四:数据被换出,由于缓存内存是有限的,当使用快满了的时候,就会使用类似LRU策略,将不经常使用的数据换出,所以也要访问数据库。

第五:后端确实也没有,应用访问缓存没有,于是查询数据库,结果数据库里面也没有,只好返回客户为空,但是尴尬的是,每次出现这种情况的时候,都会面临着一次数据库的访问,纯属浪费资源,常用的方法是,讲这个key对应的结果为空的事实也进行缓存,这样缓存可以命中,但是命中后告诉客户端没有,减少了数据库的压力。

无论哪种原因导致的读取缓存读不到的情况,该怎么办?是个策略问题。

一种是同步访问数据库后,放入缓存,再返回给客户,这样实时性最好,但是给数据库的压力也最大。

另一种方式就是异步的访问数据库,暂且返回客户一个fallback值,然后同时触发一个异步更新,这样下次就有了,这样数据库压力小很多,但是用户就访问不到实时的数据了。

3、缓存对数据库高并发访问:都来访问数据库咋办?

我们本来使用缓存,是来拦截直接访问数据库请求的,从而保证数据库大本营永远处于健康的状态。但是如果一遇到不命中,就访问数据库的话,平时没有什么问题,但是大促情况下,数据库是受不了的。

一种情况是多个客户端,并发状态下,都不命中了,于是并发的都来访问数据库,其实只需要访问一次就好,这种情况可以通过加锁,只有一个到后端来实现。

另外就是即便采取了上述的策略,依然并发量非常大,后端的数据库依然受不了,则需要通过降低实时性,将缓存拦在数据库前面,暂且撑住,来解决。

六、解决缓存三大矛盾的刷新策略

1、实时策略

所谓的实时策略,是平时缓存使用的最常用的策略,也是保持实时性最好的策略。

读取的过程,应用程序先从cache取数据,没有得到,则从数据库中取数据,成功后,放到缓存中。如果命中,应用程序从cache中取数据,取到后返回。

写入的过程,把数据存到数据库中,成功后,再让缓存失效,失效后下次读取的时候,会被写入缓存。那为什么不直接写缓存呢?因为如果两个线程同时更新数据库,一个将数据库改为10,一个将数据库改为20,数据库有自己的事务机制,可以保证如果20是后提交的,数据库里面改为20,但是回过头来写入缓存的时候就没有事务了,如果改为20的线程先更新缓存,改为10的线程后更新缓存,于是就会长时间出现缓存中是10,但是数据库中是20的现象。

这种方式实时性好,用户体验好,是默认应该使用的策略。

2、异步策略

所谓异步策略,就是当读取的时候读不到的时候,不直接访问数据库,而是返回一个fallback数据,然后往消息队列里面放入一个数据加载的事件,在背后有一个任务,收到事件后,会异步的读取数据库,由于有队列的作用,可以实现消峰,缓冲对数据库的访问,甚至可以将多个队列中的任务合并请求,合并更新缓存,提高了效率。

当更新的时候,异步策略总是先更新数据库和缓存中的一个,然后异步的更新另一个。

一是先更新数据库,然后异步更新缓存。当数据库更新后,同样生成一个异步消息,放入消息队列中,等待背后的任务通过消息进行缓存更新,同样可以实现消峰和任务合并。缺点就是实时性比较差,估计要过一段时间才能看到更新,好处是数据持久性可以得到保证。

一是先更新缓存,然后异步更新数据库。这种方式读取和写入都用缓存,将缓存完全挡在了数据库的前面,把缓存当成了数据库在用。所以一般会使用有持久化机制和主备的redis,但是仍然不能保证缓存不丢数据,所以这种情况适用于并发量大,但是数据没有那么关键的情况,好处是实时性好。

在实时策略扛不住大促的时候,可以根据场景,切换到上面的两种模式的一个,算是降级策略。

3、定时策略

如果并发量实在太大,数据量也大的情况,异步都难以满足,可以降级为定时刷新的策略,这种情况下,应用只访问缓存,不访问数据库,更新频率也不高,而且用户要求也不高,例如详情,评论等。

这种情况下,由于数据量比较大,建议将一整块数据拆分成几部分进行缓存,而且区分更新频繁的和不频繁的,这样不用每次更新的时候,所有的都更新,只更新一部分。并且缓存的时候,可以进行数据的预整合,因为实时性不高,读取预整合的数据更快。

有关缓存就说到这里,下一节讲分布式事务。

from:https://mp.weixin.qq.com/s/-9wHpKGf7aJSbtShpCcoVg

HTTP协议

我们知道目前很多应用系统中的内容传输协议采用的HTTP协议,因此不管你是前端人员、后端人员、运维人员,甚至是管理人员,都需要掌握HTTP知识!!

HTTP发展历史

HTTP/0.9  

该版本只有一个命令GET;没有HEADER等描述数据的信息; 服务器发送完毕,就关闭TCP连接。

HTTP/1.0  

该版本增加了很多命令;增加status code 和header;多字符集支持、多部分发送、权限、缓存等。

HTTP/1.1   

该版本增加了持久连接Pipeline,增加host和其他一些命令。持久连接会在HTTP特性中介绍;如果没有pipeline,那么Web服务器就需要串行处理请求,而有了pipeline,Web服务器就并行处理请求;而增加host实现了一台物理设备可以运行多个web服务。

HTTP/2.0   

所有数据以二进制传输,之前版本使用字符串进行传输;同一个连接 里面发送多个请求不再需要按照顺序来;头信息压缩以及推送等提高效率的功能。

HTTP三次握手

为什么要三次握手?因为网络是有可能延迟的,当客户端没有收到服务端的确认包,如果没有第三次握手,那么服务端不知道上次传输是不是被客户端正常接收了,如果没有接收,服务端的这个端口也是打开的,这就比较浪费资源。

HTTP报文

HTTP报文分为请求报文响应报文,请求报文和响应报文分为起始行、首部(header)和主体(body),请求报文的首部包括三部分,分别是HTTP方法、资源目录和协议,而响应报文的首部包括协议版本、状态码和状态吗对应的意思,比如200状态的意思是ok。需要注意的是:HTTP header和HTTP body之间以一行分隔。

HTTP方法  

HTTP方法定义对资源的操作,常用的有GET、POST等,这就就不详细展开了。

HTTP Code  

HTTP Code用于定义服务器对请求的处理结果,各个区间的code有不用的语义。1xx  表示信息响应类,表示接收到请求并且继续处理;2xx 表示成功;3xx 表示重定向;4xx 表示客户端出错;5xx 表示服务器出错。

HTTP特性

跨域请求   

同源策略,也就是说当两个请求的URL的协议、host和端口都相同的情况下,我们才认为这两个请求是同域的即同源,而只要协议、host和端口只要有一项是不同的,我们就认为是不同源的,即跨域,例如:

http://www.mukedada.com:80

http://www.mukedada.com:8080

上述两个请求就是跨域请求。需要注意的是跨域请求不是说浏览器限制了发起跨站请求,浏览器只是将返回结果拦截下来,最好的例子就是CSRF跨站脚本攻击。如果我们想让浏览器放行返回结果,则通过以下方法:

  1. 服务端设置Access-Control-Allow-Origin参数为允许,例如’Access-Control-Allow-Origin’ : ‘*’
  2. <link>、<img>和<script>三标签中的请求是允许跨域的,这也是JSONP的跨域做法。
Cache  Control 

对于静态资源,比如说image、js等,它们是不会经常方式变更的,而且它们的容量比较大,如果我们每次访问都要从服务器从获取相应数据,那么性能就会变得比较差,因此HTTP协议定义一些和缓存相关的参数。

可缓存性,表示在哪些地方可以缓存,比如说客户端浏览器、代理服务器等,它有三个常用的参数:public、private、no-cache。public 表明响应可以被任何对象缓存,包括发送请求的客户端浏览器、代理服务器等等;private 表示响应只能被单个用户缓存,不能作为共享缓存,即代理服务器不能缓存它;no-cache表明强制所有缓存了该响应的缓存用户,在使用已存储的缓存之前,发送带验证器的请求到源始服务器。

到期,max-age=<seconds>,设置缓存存储的最大周期,超过这个时间缓存就被认为过期。s-maxage=<seconds> 它的作用域仅在共享缓存(比如各个代理)。max-stale=<seconds> 表明客户端愿意接收一个已过期的资源。

验证,must-revalidate,缓存必须在使用之前验证旧资源的状态,并且不可使用过期资源。proxy-revalidate,与must-revalidate作用相同,但它仅适用于共享缓存(例如代理),并被私有缓存忽略。

其他。no-store,客户端和代理服务器不存储任何缓存,而是直接从服务器获取内容。no-transform:不得对资源进行转换或转变。Content-Encoding, Content-Range, Content-Type等HTTP头不能由代理修改。例如,非透明代理可以对图像格式进行转换,以便节省缓存空间或者减少缓慢链路上的流量。 no-transform指令不允许这样做。

Cookie   

服务端通过Set-Cookie将相关数据保存到浏览器中,而这些相关数据就是Cookie,那么,下次在同域的请求中就会带上这些Cookie,Cookie是键值对,可以设置多个。Cookie中通过max-age和expires设置过期时间,Secure值在https的时候发送,HttpOnly无法通过document.cookie访问。具体可以参考Session 和 Cookie

资源验证  

在Cache Control中我们介绍当设置no-cache参数时,表明每次请求都要到服务器验证,验证结果表明可以读取本地缓存才可以从本地读取缓存。只有到数据发生修改时,我们才需要从服务端读取最新数据,否则从本地读取缓存。此时,判断数据是否发生修改就变得尤为重要,通常我们采用Last-Modfied和Etag两个验证头来验证数据是否发生修改。其中Last-Modifed 通常配合If-Modified-Since或者If-UnModified-Since使用,而Etag 通常配合If-Match或者If-Non-Match使用。为了帮助大家理解,我举一个栗子。假设我们访问mudedada.com返回头信息包含:

Last-Modified:888

Etag:123

下一次访问mukedada.com的请求头中就会包含:

If-Modified-Since:888

If-Non-Match:123

服务器会比较请求头中的Last-Modified、Etag 和服务器中的对应值是否相同,如果不相同则重新获取,否则从本地缓存中获取。

长连接   

我们知道一个HTTP需要创建一个TCP连接,完成之后就关闭TCP连接,这个成本比较高(因为创建一个TCP连接需要通过三次握手),所以在HTTP/1.1开始支持长连接,请求头标识是Connection:keep-alive。如下图所示,同一个Connection ID表示同一个连接。需要注意的是同一个连接只能是同域请求。

数据协商   

数据协商指的是客户端向服务端发送请求时,客户端会声明它希望服务端返回个格式是什么?服务端根据客户端的声明来判断返回什么要的数据。其中客户端通过Accept、Accept-Encoding等参数进行设置,而服务端通过Content-Type等参数进行设置。

客户端相关参数

  1. Accept指定返回数据类型;
  2. Accept-Encoding指定服务端的数据压缩方式,目前服务端的压缩算法有gzip, deflate, br等;
  3. Accept-Language指定返回数据的语言,例如 Accept-Language:  zh-CN,zh;q=0.9,en;q=0.8,其中q表示的是权重,也就是说浏览器更希望服务器返回的是中文;
  4. User-Agent表示浏览器的相关信息,它能区分是移动端浏览器还是PC端浏览器,从而返回特定的页面。

服务端相关参数:

  1. Content-Type指的是服务端返回的数据类型;
  2. Content-Encoding对应客户端的Accept-Encoding,指的是数据压缩方式;
  3. Content-Language服务端语言。

from:https://mp.weixin.qq.com/s/vRQ2zuKxyLaBxcm9lolL7w

从零开始搭建创业公司后台技术栈

有点眼晕,以上只是我们会用到的一些语言的合集,而且只是语言层面的一部分,就整个后台技术栈来说,这只是一个开始,从语言开始,还有很多很多的内容。今天要说的后台是大后台的概念,放在服务器上的东西都属于后台的东西,比如使用的框架,语言,数据库,服务,操作系统等等,整个后台技术栈我的理解包括4个层面的内容:

  • 语言: 用了哪些开发语言,如:c++/java/go/php/python/ruby等等;
  • 组件:用了哪些组件,如:MQ组件,数据库组件等等;
  • 流程:怎样的流程和规范,如:开发流程,项目流程,发布流程,监控告警流程,代码规范等等;
  • 系统:系统化建设,上面的流程需要有系统来保证,如:规范发布流程的发布系统,代码管理系统等等;

结合以上的的4个层面的内容,整个后台技术栈的结构如图2所示:

[图2 后台技术栈结构]

以上的这些内容都需要我们从零开始搭建,在创业公司,没有大公司那些完善的基础设施,需要我们从开源界,从云服务商甚至有些需要自己去组合,去拼装,去开发一个适合自己的组件或系统以达成我们的目标。咱们一个个系统和组件的做选型,最终形成我们的后台技术栈。

一、各系统组件选型

1、项目管理/Bug管理/问题管理

项目管理软件是整个业务的需求,问题,流程等等的集中地,大家的跨部门沟通协同大多依赖于项目管理工具。有一些 SAAS 的项目管理服务可以使用,但是很多时间不满足需求,此时我们可以选择一些开源的项目,这些项目本身有一定的定制能力,有丰富的插件可以使用,一般的创业公司需求基本上都能得到满足,常用的项目如下:

  • Redmine: 用 Ruby 开发的,有较多的插件可以使用,能自定义字段,集成了项目管理,BUG 问题跟踪,WIKI 等功能,不过好多插件 N 年没有更新了;
  • Phabricator: 用 PHP 开发的,facebook 之前的内部工具,开发这工具的哥们离职后自己搞了一个公司专门做这个软件,集成了代码托管, Code Review,任务管理,文档管理,问题跟踪等功能,强烈推荐较敏捷的团队使用;
  • Jira:用 Java 开发的,有用户故事,task 拆分,燃尽图等等,可以做项目管理,也可以应用于跨部门沟通场景,较强大;
  • 悟空CRM :这个不是项目管理,这个是客户管理,之所以在这里提出来,是因为在 To B 的创业公司里面,往往是以客户为核心来做事情的,可以将项目管理和问题跟进的在悟空 CRM 上面来做,他的开源版本已经基本实现了 CR< 的核心 功能,还带有一个任务管理功能,用于问题跟进,不过用这个的话,还是需要另一个项目管理的软件协助,顺便说一嘴,这个系统的代码写得很难维护,只能适用于客户规模小(1万以内)时。

2、DNS

DNS 是一个很通用的服务,创业公司基本上选择一个合适的云厂商就行了,国内主要是两家:

  • 阿里万网:阿里 2014 年收购了万网,整合了其域名服务,最终形成了现在的阿里万网,其中就包含 DNS 这块的服务;
  • 腾讯 DNSPod: 腾讯 2012 年以 4000 万收购 DNSPod 100% 股份,主要提供域名解析和一些防护功能;

如果你的业务是在国内,主要就是这两家,选 一个就好,像今日头条这样的企业用的也是 DNSPod 的服务,除非一些特殊的原因才需要自建,比如一些 CDN 厂商,或者对区域有特殊限制的。要实惠一点用阿里最便宜的基础版就好了,要成功率高一些,还是用DNSPod 的贵的那种。

在国外还是选择亚马逊吧,阿里的 DNS 服务只有在日本和美国有节点,东南亚最近才开始部点, DNSPod 也只有美国和日本,像一些出海的企业,其选择的云服务基本都是亚马逊。

如果是线上产品,DNS 强烈建议用付费版,阿里的那几十块钱的付费版基本可以满足需求。如果还需要一些按省份或按区域调试的逻辑,则需要加钱,一年也就几百块,省钱省力。

如果是国外,优先选择亚马逊,如果需要国内外互通并且有自己的 APP 的话,建议还是自己实现一些容灾逻辑或者智能调度,因为没有一个现成的 DNS 服务能同时较好的满足国内外场景,或者用多个域名,不同的域名走不同的 DNS 。

3、LB(负载均衡)

LB(负载均衡)是一个通用服务,一般云厂商的 LB 服务基本都会如下功能:

  • 支持四层协议请求(包括 TCP、UDP 协议);
  • 支持七层协议请求(包括 HTTP、HTTPS 协议);
  • 集中化的证书管理系统支持 HTTPS 协议;
  • 健康检查;

如果你线上的服务机器都是用的云服务,并且是在同一个云服务商的话,可以直接使用云服务商提供的 LB 服务,如阿里云的 SLB,腾讯云的 CLB, 亚马逊 的 ELB 等等。如果是自建机房基本都是 LVS + Nginx。

4、CDN

CDN 现在已经是一个很红很红的市场,基本上只能挣一些辛苦钱,都是贴着成本在卖。国内以网宿为龙头,他们家占据整个国内市场份额的40%以上,后面就是腾讯,阿里。网宿有很大一部分是因为直播的兴起而崛起。

国外,Amazon 和 Akamai 合起来占比大概在 50%,曾经的国际市场老大 Akamai 拥有全球超一半的份额,在 Amazon CDN入局后,份额跌去了将近 20%,众多中小企业都转向后者,Akamai 也是无能为力。

国内出海的 CDN 厂商,更多的是为国内的出海企业服务,三家大一点的 CDN 服务商里面也就网宿的节点多一些,但是也多不了多少。阿里和腾讯还处于前期阶段,仅少部分国家有节点。

就创业公司来说,CDN 用腾讯云或阿里云即可,其相关系统较完善,能轻松接入,网宿在系统支持层面相对较弱一些,而且还贵一些。并且,当流量上来后,CDN 不能只用一家,需要用多家,不同的 CDN 在全国的节点覆盖不一样,而且针对不同的客户云厂商内部有些区分客户集群,并不是全节点覆盖(但有些云厂商说自己是全网节点),除了节点覆盖的问题,多 CDN 也在一定程度上起到容灾的作用。

5、RPC框架

维基百科对 RPC 的定义是:远程过程调用(Remote Procedure Call,RPC)是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序,而程序员无需额外地为这个交互作用编程。

通俗来讲,一个完整的RPC调用过程,就是 Server 端实现了一个函数,客户端使用 RPC 框架提供的接口,调用这个函数的实现,并获取返回值的过程。

业界 RPC 框架大致分为两大流派,一种侧重跨语言调用,另一种是偏重服务治理。

跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用,能够支持大部分的语言进行语言无关的调用,非常适合多语言调用场景。但这类框架没有服务发现相关机制,实际使用时需要代理层进行请求转发和负载均衡策略控制。

其中,gRPC 是 Google 开发的高性能、通用的开源 RPC 框架,其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计,基于 ProtoBuf(Protocol Buffers) 序列化协议开发,且支持众多开发语言。本身它不是分布式的,所以要实现框架的功能需要进一步的开发。

Hprose(High Performance Remote Object Service Engine) 是一个 MIT 开源许可的新型轻量级跨语言跨平台的面向对象的高性能远程动态通讯中间件。

服务治理型的 RPC 框架的特点是功能丰富,提供高性能的远程调用、服务发现及服务治理能力,适用于大型服务的服务解耦及服务治理,对于特定语言(Java)的项目可以实现透明化接入。缺点是语言耦合度较高,跨语言支持难度较大。国内常见的冶理型 RPC 框架如下:

  • Dubbo: Dubbo 是阿里巴巴公司开源的一个 Java 高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring 框架无缝集成。当年在淘宝内部,Dubbo 由于跟淘宝另一个类似的框架 HSF 有竞争关系,导致 Dubbo 团队解散,最近又活过来了,有专职同学投入。
  • DubboX: DubboX 是由当当在基于 Dubbo 框架扩展的一个 RPC 框架,支持 REST 风格的远程调用、Kryo/FST 序列化,增加了一些新的feature。
  • Motan: Motan 是新浪微博开源的一个 Java 框架。它诞生的比较晚,起于 2013 年,2016 年 5 月开源。Motan 在微博平台中已经广泛应用,每天为数百个服务完成近千亿次的调用。
  • rpcx: rpcx 是一个类似阿里巴巴 Dubbo 和微博  Motan 的分布式的 RPC 服务框架,基于 Golang net/rpc 实现。但是 rpcx 基本只有一个人在维护,没有完善的社区,使用前要慎重,之前做 Golang 的 RPC 选型时也有考虑这个,最终还是放弃了,选择了 gRPC,如果想自己自研一个 RPC 框架,可以参考学习一下。

6、名字发现/服务发现

名字发现和服务发现分为两种模式,一个是客户端发现模式,一种是服务端发现模式。

框架中常用的服务发现是客户端发现模式。

所谓服务端发现模式是指客户端通过一个负载均衡器向服务发送请求,负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。现在常用的负载均衡器都是此类模式,常用于微服务中。

所有的名字发现和服务发现都要依赖于一个可用性非常高的服务注册表,业界常用的服务注册表有如下三个:

  • etcd,一个高可用、分布式、一致性、key-value方式的存储,被用在分享配置和服务发现中。两个著名的项目使用了它:k8s和Cloud Foundry。
  • consul,一个发现和配置服务的工具,为客户端注册和发现服务提供了API,Consul还可以通过执行健康检查决定服务的可用性。
  • Apache Zookeeper,是一个广泛使用、高性能的针对分布式应用的协调服务。Apache Zookeeper本来是 Hadoop 的子工程,现在已经是顶级工程了。

除此之外也可以自己实现服务实现,或者用 Redis 也行,只是需要自己实现高可用性。

7、关系数据库

关系数据库分为两种,一种是传统关系数据,如 Oracle, MySQL,Maria, DB2,PostgreSQL 等等,另一种是 NewSQL,即至少要满足以下五点的新型关系数据库:

  1. 完整地支持SQL,支持JOIN / GROUP BY /子查询等复杂SQL查询;
  2. 支持传统数据标配的 ACID 事务,支持强隔离级别。
  3. 具有弹性伸缩的能力,扩容缩容对于业务层完全透明。
  4. 真正的高可用,异地多活、故障恢复的过程不需要人为的接入,系统能够自动地容灾和进行强一致的数据恢复。
  5. 具备一定的大数据分析能力

传统关系数据库用得最多的是 MySQL,成熟,稳定,一些基本的需求都能满足,在一定数据量级之前基本单机传统数据库都可以搞定,而且现在较多的开源系统都是基于 MySQL,开箱即用,再加上主从同步和前端缓存,百万 pv 的应用都可以搞定了。不过 CentOS 7 已经放弃了 MySQL,而改使用 MariaDB。MariaDB 数据库管理系统是 MySQ L的一个分支,主要由开源社区在维护,采用GPL 授权许可。开发这个分支的原因之一是:甲骨文公司收购了 MySQL 后,有将 MySQ L闭源的潜在风险,因此社区采用分支的方式来避开这个风险。

在 Google 发布了  F1: A Distributed SQL Database That Scales 和  Spanner: Google’s Globally-Distributed Databasa 之后,业界开始流行起 NewSQL。于是有了 CockroachDB,于是有了 奇叔公司的 TiDB。国内已经有比较多的公司使用 TiDB,之前在创业公司时在大数据分析时已经开始应用 TiDB,当时应用的主要原因是 MySQL 要使用分库分表,逻辑开发比较复杂,扩展性不够。

8、NoSQL

NoSQL 顾名思义就是 Not-Only SQL,也有人说是 No – SQL, 个人偏向于Not – Only SQL,它并不是用来替代关系库,而是作为关系型数据库的补充而存在。

常见 NoSQL 有4个类型:

  1. 键值,适用于内容缓存,适合混合工作负载并发高扩展要求大的数据集,其优点是简单,查询速度快,缺点是缺少结构化数据,常见的有 Redis, Memcache, BerkeleyDB 和 Voldemort 等等;
  2. 列式,以列簇式存储,将同一列数据存在一起,常见于分布式的文件系统,其中以 Hbase,Cassandra 为代表。Cassandra 多用于写多读少的场景,国内用得比较多的有 360,大概 1500 台机器的集群,国外大规模使用的公司比较多,如 Ebay,Instagram,Apple 和沃尔玛等等;
  3. 文档,数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息。性能介于 kv 和关系数据库之间,它的灵感来于 lotus notes,常见的有 MongoDB,CouchDB 等等;
  4. 图形,图形数据库擅长处理任何涉及关系的状况。社交网络,推荐系统等。专注于构建关系图谱,需要对整个图做计算才能得出结果,不容易做分布式的集群方案,常见的有 Neo4J,InfoGrid 等。

除了以上4种类型,还有一些特种的数据库,如对象数据库,XML 数据库,这些都有针对性对某些存储类型做了优化的数据库。

在实际应用场景中,何时使用关系数据库,何时使用 NoSQL,使用哪种类型的数据库,这是我们在做架构选型时一个非常重要的考量,甚至会影响整个架构的方案。

9、消息中间件

消息中间件在后台系统中是必不可少的一个组件,一般我们会在以下场景中使用消息中间件:

  • 异步处理:异步处理是使用消息中间件的一个主要原因,在工作中最常见的异步场景有用户注册成功后需要发送注册成功邮件、缓存过期时先返回老的数据,然后异步更新缓存、异步写日志等等;通过异步处理,可以减少主流程的等待响应时间,让非主流程或者非重要业务通过消息中间件做集中的异步处理。
  • 系统解耦:比如在电商系统中,当用户成功支付完成订单后,需要将支付结果给通知ERP系统、发票系统、WMS、推荐系统、搜索系统、风控系统等进行业务处理;这些业务处理不需要实时处理、不需要强一致,只需要最终一致性即可,因此可以通过消息中间件进行系统解耦。通过这种系统解耦还可以应对未来不明确的系统需求。
  • 削峰填谷:当系统遇到大流量时,监控图上会看到一个一个的山峰样的流量图,通过使用消息中间件将大流量的请求放入队列,通过消费者程序将队列中的处理请求慢慢消化,达到消峰填谷的效果。最典型的场景是秒杀系统,在电商的秒杀系统中下单服务往往会是系统的瓶颈,因为下单需要对库存等做数据库操作,需要保证强一致性,此时使用消息中间件进行下单排队和流控,让下单服务慢慢把队列中的单处理完,保护下单服务,以达到削峰填谷的作用。

业界消息中间件是一个非常通用的东西,大家在做选型时有使用开源的,也有自己造轮子的,甚至有直接用 MySQL 或 Redis 做队列的,关键看是否满足你的需求,如果是使用开源的项目,以下的表格在选型时可以参考:

[图3]

以上图的纬度为:名字 成熟度所属社区/公司 文档 授权方式 开发语言支持的协议 客户端支持的语言 性能 持久化 事务 集群 负载均衡 管理界面 部署方式 评价

10 、代 码管理

代码是互联网创业公司的命脉之一,代码管理很重要,常见的考量点包括两块:

  • 安全和权限管理,将代码放到内网并且对于关系公司命脉的核心代码做严格的代码控制和机器的物理隔离;
  • 代码管理工具,Git 作为代码管理的不二之选,你值得拥有。Gitlab 是当今最火的开源 Git 托管服务端,没有之一,虽然有企业版,但是其社区版基本能满足我们大部分需求,结合 Gerrit 做 Code review,基本就完美了。当然 Gitlab 也有代码对比,但没Gerrit 直观。Gerrit 比 Gitlab 提供了更好的代码检查界面与主线管理体验,更适合在对代码质量有高要求的文化下使用。

11、持续集成

持续集成简,称 CI(continuous integration), 是一种软件开发实践,即团队开发成员经常集成他们的工作,每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。持续集成为研发流程提供了代码分支管理/比对、编译、检查、发布物输出等基础工作,为测试的覆盖率版本编译、生成等提供统一支持。

业界免费的持续集成工具中系统我们有如下一些选择:

  • Jenkins:Jjava写的 有强大的插件机制,MIT协议开源 (免费,定制化程度高,它可以在多台机器上进行分布式地构建和负载测试)。Jenkins可以算是无所不能,基本没有 Jenkins 做不了的,无论从小型团队到大型团队 Jenkins 都可以搞定。 不过如果要大规模使用,还是需要有人力来学习和维护。
  • TeamCity: TeamCity与Jenkins相比使用更加友好,也是一个高度可定制化的平台。但是用的人多了,TeamCity就要收费了。
  • Strider: Strider 是一个开源的持续集成和部署平台,使用 Node.js 实现,存储使用的是 MongoDB,BSD 许可证,概念上类似 Travis 和Jenkins。
  • GitLabCI:从GitLab8.0开始,GitLab CI 就已经集成在 GitLab,我们只要在项目中添加一个 .gitlab-ci.yml 文件,然后添加一个Runner,即可进行持续集成。并且 Gitlab 与 Docker 有着非常好的相互协作的能力。免费版与付费版本不同可以参见这里: https://about.gitlab.com/products/feature-comparison/
  • Travis:Travis 和 Github 强关联;闭源代码使用 SaaS 还需考虑安全问题; 不可定制;开源项目免费,其它收费;
  • Go: Go是ThoughtWorks公司最新的Cruise Control的化身。除了 ThoughtWorks 提供的商业支持,Go是免费的。它适用于Windows,Mac和各种Linux发行版。

12、日志系统

日志系统一般包括打日志,采集,中转,收集,存储,分析,呈现,搜索还有分发等。一些特殊的如染色,全链条跟踪或者监控都可能需要依赖于日志系统实现。日志系统的建设不仅仅是工具的建设,还有规范和组件的建设,最好一些基本的日志在框架和组件层面加就行了,比如全链接跟踪之类的。

对于常规日志系统ELK能满足大部分的需求,ELK 包括如下组件:

  • ElasticSearch 是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。
  • Logstash 是一个完全开源的工具,它可以对你的日志进行收集、分析,并将其存储供以后使用。
  • Kibana 是一个开源和免费的工具,它可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面,可以帮助汇总、分析和搜索重要数据日志。

Filebeat 已经完全替代了 Logstash-Forwarder 成为新一代的日志采集器,同时鉴于它轻量、安全等特点,越来越多人开始使用它。

因为免费的 ELK 没有任何安全机制,所以这里使用了 Nginx 作反向代理,避免用户直接访问 Kibana 服务器。加上配置 Nginx 实现简单的用户认证,一定程度上提高安全性。另外,Nginx 本身具有负载均衡的作用,能够提高系统访问性能。ELK 架构如图4所示:

[图4] ELK 流程图

对于有实时计算的需求,可以使用 Flume+Kafka+Storm+MySQL方案,一 般架构如图5所示:

[图5] 实时分析系统架构图

其中:

  • Flume 是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的日志收集系统,支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume 提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。
  • Kafka 是由 Apache 软件基金会开发的一个开源流处理平台,由 Scala 和 Java 编写。其本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”,它以可水平扩展和高吞吐率而被广泛使用。

Kafka 追求的是高吞吐量、高负载,Flume 追求的是数据的多样性,二者结合起来简直完美。

13、监控系统

监控系统只包含与后台相关的,这里主要是两块,一个是操作系统层的监控,比如机器负载,IO,网络流量,CPU,内存等操作系统指标的监控。另一个是服务质量和业务质量的监控,比如服务的可用性,成功率,失败率,容量,QPS 等等。常见业务的监控系统先有操作系统层面的监控(这部分较成熟),然后扩展出其它监控,如 zabbix,小米的 open-falcon,也有一出来就是两者都支持的,如 prometheu s。如果对业务监控要求比较高一些,在创业选型中建议可以优先考虑 prometheus。这里有一个有趣的分布,如图6所示

[图6 监控系统分布]

亚洲区域使用 zabbix 较多,而美洲和欧洲,以及澳大利亚使用 prometheus 居多,换句话说,英文国家地区(发达国家?)使用prometheus 较多。

Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库( TSDB )。Prometheus 使用 Go 语言开发,是 Google BorgMon 监控系统的开源版本。相对于其它监控系统使用的 push 数据的方式,prometheus 使用的是 pull 的方式,其架构如图7所示:

[图7] prometheus架构图

如上图所示,prometheus 包含的主要组件如下:

  • Prometheus Server 主要负责数据采集和存储,提供 PromQL 查询语言的支持。Server 通过配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目标。根据这些目标会,Server 定时去抓取 metric s数据,每个抓取目标需要暴露一个 http 服务的接口给它定时抓取。
  • 客户端SDK:官方提供的客户端类库有 go、java、scala、python、ruby,其他还有很多第三方开发的类库,支持 nodejs、php、erlang 等。
  • Push Gateway 支持临时性 Job 主动推送指标的中间网关。
  • Exporter Exporter 是Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据,并将其转化为 Prometheus 支持的格式。与传统的数据采集组件不同的是,它并不向中央服务器发送数据,而是等待中央服务器主动前来抓取。Prometheus提供多种类型的 Exporter 用于采集各种不同服务的运行状态。目前支持的有数据库、硬件、消息中间件、存储系统、HTTP服务器、JMX等。
  • alertmanager:是一个单独的服务,可以支持 Prometheus 的查询语句,提供十分灵活的报警方式。
  • Prometheus HTTP API的查询方式,自定义所需要的输出。
  • Grafana 是一套开源的分析监视平台,支持 Graphite, InfluxDB, OpenTSDB, Prometheus, Elasticsearch, CloudWatch 等数据源,其 UI 非常漂亮且高度定制化。

创业公司选择 Prometheus + Grafana 的方案,再加上统一的服务框架(如 gRPC ),可以满足大部分中小团队的监控需求。

14、配置系统

随着程序功能的日益复杂,程序的配置日益增多:各种功能的开关、降级开关,灰度开关,参数的配置、服务器的地址、数据库配置等等,除此之外,对后台程序配置的要求也越来越高:配置修改后实时生效,灰度发布,分环境、分用户,分集群管理配置,完善的权限、审核机制等等,在这样的大环境下,传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求,业界有如下两种方案:

  • 基于 zk 和 etcd,支持界面和 api ,用数据库来保存版本历史,预案,走审核流程,最后下发到 zk 或 etcd 这种有推送能力的存储里(服务注册本身也是用 zk 或 etcd,选型就一块了)。客户端都直接和 zk 或 etcd 打交道。至于灰度发布,各家不同,有一种实现是同时发布一个需要灰度的 IP 列表,客户端监听到配置节点变化时,对比一下自己是否属于该列表。PHP 这种无状态的语言和其他 zk/etcd 不支持的语言,只好自己在客户端的机器上起一个 Agent 来监听变化,再写到配置文件或共享内存,如 360 的 Qconf。
  • 基于运维自动化的配置文件的推送,审核流程,配置数据管理和方案一类似,下发时生成配置文件,基于运维自动化工具如Puppet,Ansible 推送到每个客户端,而应用则定时重新读取这个外部的配置文件,灰度发布在下发配置时指定IP列表。

创业公司前期不需要这种复杂,直接上 zk,弄一个界面管理 zk 的内容,记录一下所有人的操作日志,程序直连 zk,或者或者用Qconf 等基于 zk 优化后的方案。

15、发布系统/部署系统

从软件生产的层面看,代码到最终服务的典型流程如图8所示:

[图8 流程图]

从上图中可以看出,从开发人员写下代码到服务最终用户是一个漫长过程,整体可以分成三个阶段:

  • 从代码(Code)到成品库(Artifact)这个阶段主要对开发人员的代码做持续构建并把构建产生的制品集中管理,是为部署系统准备输入内容的阶段。
  • 从制品到可运行服务 这个阶段主要完成制品部署到指定环境,是部署系统的最基本工作内容。
  • 从开发环境到最终生产环境 这个阶段主要完成一次变更在不同环境的迁移,是部署系统上线最终服务的核心能力。

发布系统集成了制品管理,发布流程,权限控制,线上环境版本变更,灰度发布,线上服务回滚等几方面的内容,是开发人员工作结晶最终呈现的重要通道。开源的项目中没有完全满足的项目,如果只是 Web 类项目,Walle、Piplin 都是可用的,但是功能不太满足,创业初期可以集成 Jenkins + Gitlab + Walle (可以考虑两天时间完善一下),以上方案基本包括 制品管理,发布流程,权限控制,线上环境版本变更,灰度发布(需要自己实现),线上服务回滚等功能。

16、跳板机

跳板机面对的是需求是要有一种能满足角色管理与授权审批、信息资源访问控制、操作记录和审计、系统变更和维护控制要求,并生成一些统计报表配合管理规范来不断提升IT内控的合规性,能对运维人员操作行为的进行控制和审计,对误操作、违规操作导致的操作事故,快速定位原因和责任人。其功能模块一般包括:帐户管理、认证管理、授权管理、审计管理等等

开源项目中,Jumpserver 能够实现跳板机常见需求,如授权、用户管理、服务器基本信息记录等,同时又可批量执行脚本等功能;其中录像回放、命令搜索、实时监控等特点,又能帮助运维人员回溯操作历史,方便查找操作痕迹,便于管理其他人员对服务器的操作控制。

17、机器管理

机器管理的工具选择的考量可以包含以下三个方面:

  1. 是否简单,是否需要每台机器部署agent(客户端)
  2. 语言的选择(puppet/chef vsansible/saltstack)开源技术,不看官网不足以熟练,不懂源码不足以精通;Puppet、Chef基于Ruby开发,ansible、saltstack基于python开发的
  3. 速度的选择(ansiblevssaltstack) ansible基于SSH协议传输数据,Saltstack使用消息队列zeroMQ传输数据;大规模并发的能力对于几十台-200台规模的兄弟来讲,ansible的性能也可接受,如果一次操作上千台,用salt好一些。

如图9所示:

[图9 机器管理软件对比]

一般创业公司选择 Ansible 能解决大部问题,其简单,不需要安装额外的客户端,可以从命令行来运行,不需要使用配置文件。至于比较复杂的任务,Ansible 配置通过名为 Playbook 的配置文件中的 YAML 语法来加以处理。Playbook 还可以使用模板来扩展其功能。

二、创业公司的选择

1、选择合适的语言

  • 选择团队熟悉的/能掌控的,创业公司人少事多,无太多冗余让研发团队熟悉新的语言,能快速上手,能快速出活,出了问题能快速解决的问题的语言才是好的选择。
  • 选择更现代一些的,这里的现代是指语言本身已经完成一些之前需要特殊处理的特性,比如内存管理,线程等等。
  • 选择开源轮子多的或者社区活跃度高的,这个原则是为了保证在开发过程中减少投入,有稳定可靠的轮子可以使用,遇到问题可以在网上快速搜索到答案。
  • 选择好招人的 一门合适的语言会让创业团队减少招聘的成本,快速招到合适的人。
  • 选择能让人有兴趣的 与上面一点相关,让人感兴趣,在后面留人时有用。

2、选择合适的组件和云服务商

  • 选择靠谱的云服务商;
  • 选择云服务商的组件;
  • 选择成熟的开源组件,而不是最新出的组件;
  • 选择采用在一线互联网公司落地并且开源的,且在社区内形成良好口碑的产品;
  • 开源社区活跃度;

选择靠谱的云服务商,其实这是一个伪命题,因为哪个服务商都不靠谱,他们所承诺的那些可用性问题基本上都会在你的身上发生,这里我们还是需要自己做一些工作,比如多服务商备份,如用CDN,你一定不要只选一家,至少选两家,一个是灾备,保持后台切换的能力,另一个是多点覆盖,不同的服务商在CDN节点上的资源是不一样的。

选择了云服务商以后,就会有很多的产品你可以选择了,比较存储,队列这些都会有现成的产品,这个时候就纠结了,是用呢?还是自己在云主机上搭呢?在这里我的建议是前期先用云服务商的,大了后再自己搞,这样会少掉很多运维的事情,但是这里要多了解一下云服务商的组件特性以及一些坑,比如他们内网会经常断开,他们升级也会闪断,所以在业务侧要做好容错和规避。

关于开源组件,尽可能选择成熟的,成熟的组件经历了时间的考验,基本不会出大的问题,并且有成套的配套工具,出了问题在网上也可以很快的找到答案,你所遇到的坑基本上都有人踩过了。

3、制定流程和规范

  • 制定开发的规范,代码及代码分支管理规范,关键性代码仅少数人有权限;
  • 制定发布流程规范,从发布系统落地;
  • 制定运维规范;
  • 制定数据库操作规范,收拢数据库操作权限;
  • 制定告警处理流程,做到告警有人看有人处理;
  • 制定汇报机制,晨会/周报;

4、自研和选型合适的辅助系统

所有的流程和规范都需要用系统来固化,否则就是空中楼阁,如何选择这些系统呢?参照上个章节咱们那些开源的,对比一下选择的语言,组件之类的,选择一个最合适的即可。

比如项目管理的,看下自己是什么类型的公司,开发的节奏是怎样的,瀑布,敏捷的 按项目划分,还是按客户划分等等,平时是按项目组织还是按任务组织等等

比如日志系统,之前是打的文本,那么上一个elk,规范化一些日志组件,基本上很长一段时间内不用考虑日志系统的问题,最多拆分一下或者扩容一下。等到组织大了,自己搞一个日志系统。

比如代码管理,项目管理系统这些都放内网,安全,在互联网公司来说,属于命脉了,命脉的东西还是放在别人拿不到或很难拿到的地方会比较靠谱一些。

5、选择过程中需要思考的问题

技术栈的选择有点像做出了某种承诺,在一定的时间内这种承诺没法改变,于是我们需要在选择的时候有一些思考。

看前面内容,有一个词出现了三次,合适,选择是合适的,不是最好,也不是最新,是最合适,适合是针对当下,这种选择是最合适的吗?比如用 Go 这条线的东西,技术比较新,业界组件储备够吗?组织内的人员储备够吗?学习成本多少?写出来的东西能满足业务性能要求吗?能满足时间要求吗?

向未来看一眼,在一年到三年内,我们需要做出改变吗?技术栈要做根本性的改变吗?如果组织发展很快,在 200 人,500 人时,现有的技术栈是否需要大动?

创业过程中需要考虑成本,这里的成本不仅仅是花费多少钱,付出多少工资,有时更重要的是时间成本,很多业务在创业时大家拼的就是时间,就是一个时间窗,过了就没你什么事儿了。

三、基于云的创业公司后台技术架构

结合上面内容的考量,在对一个个系统和组件的做选型之后,以云服务为基础,一个创业公司的后台技术架构如图10所示:

[图10 后台技术架构]

参考资料

http://database.51cto.com/art/201109/291781.htm

https://zh.wikipedia.org/wiki/Kafka

https://prometheus.io/docs/introduction/overview/

http://deadline.top/2016/11/23/配置中心那点事/

http://blog.fit2cloud.com/2016/01/26/deployment-system.html

from:http://www.phppan.com/2018/04/svr-stack/