O******t
发帖数: 214 | 1 前提 #1：
客户没有budget限制，
只要确实需要，投多少钱都可以，
前提就是别浪费，别胡搞。
前提 #2：
我自己这里就是能省事就省事，
以干最少的事情保证客户的需求为最大目的。
详情如下：
开发初期：
几年前给客户做了一个CMS+网站，
后台更新量比较频繁，大概20多个人全职更新内容。
因为更新的各类要求比较变态，
开发初期为了节约时间成本，前台直接就上了动态，做了一点cache优化。
business增长期：
最近2，3年，客户网站流量暴增，
尤其是holiday season前后，经常出暴击spike。
现在：
本来想搞AWS或者azure的，
但是人力有限，没有深入研究。
所以单纯搞了一个cache server，
CMS更新之后的内容，
全部由cms server generate成纯静态内容push到cache server上。
然后由cache server承载流量，
勉勉强强过得还算可以。
未来：
拜读了几位的帖子，+研究了一下AWS，和AZURE等，
打算未来CMS方面不变，继续还是沿用目前的方式，毕竟只是内部人员操作，
然后cache server改成用AWS或其他cloud等。
请各路大神分析指点批判。 |
B***i
发帖数: 724 | |
e*****t
发帖数: 1005 | 3 have you tried any CDN? Or that is what you meant by "caching"?
【在 O******t 的大作中提到】
: 前提 #1：
: 客户没有budget限制，
: 只要确实需要，投多少钱都可以，
: 前提就是别浪费，别胡搞。
: 前提 #2：
: 我自己这里就是能省事就省事，
: 以干最少的事情保证客户的需求为最大目的。
: 详情如下：
: 开发初期：
: 几年前给客户做了一个CMS+网站，
|
g*****g
发帖数: 34805 | 4 你的架构其实做得很好，需要的就是把你的cache server扔到aws上，用autoscale来
应付spike即可。节假日之前可以预先scale up。
【在 O******t 的大作中提到】
: 前提 #1：
: 客户没有budget限制，
: 只要确实需要，投多少钱都可以，
: 前提就是别浪费，别胡搞。
: 前提 #2：
: 我自己这里就是能省事就省事，
: 以干最少的事情保证客户的需求为最大目的。
: 详情如下：
: 开发初期：
: 几年前给客户做了一个CMS+网站，
|
d********u
发帖数: 5383 | 5 觉得LZ的CACHING就是普通意义上的缓存，没觉得有乾坤大挪移的意思，不像对CDN有需
求的样子。关键LZ要搞清楚，你的流量是常年很高还是就是假日的时候高。常年很高加
SERVER就好了，不需要弹性的。
【在 e*****t 的大作中提到】
: have you tried any CDN? Or that is what you meant by "caching"?
|
d********u
发帖数: 5383 | 6 Bonzi，你现在退役了?
【在 B***i 的大作中提到】
: 几个server? 直接加服务器不行吗？
|
O******t
发帖数: 214 | 7 直接加服务器，平时太浪费。
spike期间的consuming可能是平时的50倍，甚至100倍。
【在 B***i 的大作中提到】
: 几个server? 直接加服务器不行吗？
|
O******t
发帖数: 214 | 8 No, There's only 1 front end content server for visitors now.
Also, Most of users located in US East.
Cache is my own define word.
It means Pushing content to Front-end instead of pulling content by Front-
end Function.
【在 e*****t 的大作中提到】
: have you tried any CDN? Or that is what you meant by "caching"?
|
O******t
发帖数: 214 | 9 多谢，autoscale是需要提前设置，还是aws自己根据情况而定？
【在 g*****g 的大作中提到】
: 你的架构其实做得很好，需要的就是把你的cache server扔到aws上，用autoscale来
: 应付spike即可。节假日之前可以预先scale up。
|
O******t
发帖数: 214 | 10 应该是普通意义的缓存，
对CDN确实没需求，客户基本集中在2个区域，目前也只有1台前端server。
弹性方案比较好，每年都是holiday season忙一下，其他月份都很淡。
请教一下什么是乾坤大挪移？
【在 d********u 的大作中提到】
: 觉得LZ的CACHING就是普通意义上的缓存，没觉得有乾坤大挪移的意思，不像对CDN有需
: 求的样子。关键LZ要搞清楚，你的流量是常年很高还是就是假日的时候高。常年很高加
: SERVER就好了，不需要弹性的。
|
|
|
g*****g
发帖数: 34805 | 11 Autoscale is a policy you define, it can be time-based, cpu usage based,
memory usage based etc. You can always say scale up when cpu usage is over
60%. But it's also better to scale up ahead of your high usage time and
scale down after.
【在 O******t 的大作中提到】
: 多谢，autoscale是需要提前设置，还是aws自己根据情况而定？
|
z****e
发帖数: 54598 | 12 每年都是holiday season忙一下，其他月份都很淡。
这个是cloud的主场
【在 O******t 的大作中提到】
: 应该是普通意义的缓存，
: 对CDN确实没需求，客户基本集中在2个区域，目前也只有1台前端server。
: 弹性方案比较好，每年都是holiday season忙一下，其他月份都很淡。
: 请教一下什么是乾坤大挪移？
|
d********u
发帖数: 5383 | 13 对。
【在 z****e 的大作中提到】
: 每年都是holiday season忙一下，其他月份都很淡。
: 这个是cloud的主场
|
s***o
发帖数: 2191 | 14 这个还要研究一下spike期间read/write的pattern吧？你现在的cache server好像主要
解决的是read的问题？ |
O******t
发帖数: 214 | 15 能否详细说说？
【在 s***o 的大作中提到】
: 这个还要研究一下spike期间read/write的pattern吧？你现在的cache server好像主要
: 解决的是read的问题？
|
g*****g
发帖数: 34805 | 16 It's a CMS, write is few and between and it doesn't have to reflect in cache
server in real time.
【在 s***o 的大作中提到】
: 这个还要研究一下spike期间read/write的pattern吧？你现在的cache server好像主要
: 解决的是read的问题？
|
s***o
发帖数: 2191 | 17 not from the CMS end, but the clients end, for example, to handle situations
like touchpad fire-sale. I assume their clients actually "buy" things?
cache
【在 g*****g 的大作中提到】
: It's a CMS, write is few and between and it doesn't have to reflect in cache
: server in real time.
|
s***o
发帖数: 2191 | 18 http://stblog.baidu-tech.com/?p=1643
这个是我以前看过的一篇文章，虽然不是针对专门spike的，可能你会从中找到一些有
用信息
【在 O******t 的大作中提到】
: 能否详细说说？
|
g*****g
发帖数: 34805 | 19 很好的文章。说到底高并发最后的主要问题都在数据库的处理上。传统RDBMS很强大很
方便，但不scale out。解决方案就是把不需要transaction的部分拿出去扔到cache和
NoSQL里，把所有非存储的商业逻辑扔到app server上 (不用stored procedure)。把需
要transaction的部分尽量水平和垂直上划分使得单个RDMBS需要处理的数据量尽量小。
还不够的话只能批量处理transaction但这时候就会产生一些consistency的问题。架构
最大的难度，在于如何划分数据库，用什么样的cache和NoSQL，这些都是跟数据的特性
相关的。不同数据对CA的容忍度不同，需要对商业逻辑有深入理解以及不同Cache/
NoSQL有深入经验。
【在 s***o 的大作中提到】
: http://stblog.baidu-tech.com/?p=1643
: 这个是我以前看过的一篇文章，虽然不是针对专门spike的，可能你会从中找到一些有
: 用信息
|
O******t
发帖数: 214 | 20 收藏了，多谢。
【在 s***o 的大作中提到】
: http://stblog.baidu-tech.com/?p=1643
: 这个是我以前看过的一篇文章，虽然不是针对专门spike的，可能你会从中找到一些有
: 用信息
|
v*****r
发帖数: 2325 | 21 好虫是做software architect, 或做很多涉及IT architecture/infrastructure? 讲讲
做架构的条件,工作性质吧.Thank u!
【在 g*****g 的大作中提到】
: Autoscale is a policy you define, it can be time-based, cpu usage based,
: memory usage based etc. You can always say scale up when cpu usage is over
: 60%. But it's also better to scale up ahead of your high usage time and
: scale down after.
|
c******o
发帖数: 1277 | |
