e******0
发帖数: 291 | 1 open question:
假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越好,比如前期成
本,开发维护, 后面如何方便升级, scale up等等... as much as you know
我看板上大牛们常常讨论这个的样子, 不明觉厉, 但是我等菜鸟实在缺乏经验, 大牛们
讨论的我能看懂的也不多.只知道几个比较传统老旧的比如LAMP之类的还有就是自己有
过经验的, 高端大气上档次点的比如如何scale, nosql之类等等我没用过也是白扯.
当时扯了扯自己会的, 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
基本属于暴兵流(就是人海战术的意思,不求个体的质量, 只以总量取胜), 每个
instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
别多的instance. 当然再细究他们怎么做到这么多instance的协作的时候,又成小白了,
大牛们指点下迷津吧, 说实话我觉得这些东
西真的是太需要实际经验了,亚麻那个面试官年纪轻轻的, 我觉得他也就懂他们系统里
那一套, 我搬了点大牛们常在版上讨论的名词出来, 他也不懂. | l****o
发帖数: 315 | 2 我去。。。你是new grad吗？ 感觉当年我要被面了这个可能就拿不到offer了。 | e******0
发帖数: 291 | 3 只能说, 不算是....
【在 l****o 的大作中提到】
: 我去。。。你是new grad吗？ 感觉当年我要被面了这个可能就拿不到offer了。
| p*****2
发帖数: 21240 | | z****e
发帖数: 54598 | 5
这种问题，无脑上java，维护成本，升级，scale up这些参考netflix
,
【在 e******0 的大作中提到】
: open question:
: 假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越好,比如前期成
: 本,开发维护, 后面如何方便升级, scale up等等... as much as you know
: 我看板上大牛们常常讨论这个的样子, 不明觉厉, 但是我等菜鸟实在缺乏经验, 大牛们
: 讨论的我能看懂的也不多.只知道几个比较传统老旧的比如LAMP之类的还有就是自己有
: 过经验的, 高端大气上档次点的比如如何scale, nosql之类等等我没用过也是白扯.
: 当时扯了扯自己会的, 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
: 基本属于暴兵流(就是人海战术的意思,不求个体的质量, 只以总量取胜), 每个
: instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
: 别多的instance. 当然再细究他们怎么做到这么多instance的协作的时候,又成小白了,
| z****e
发帖数: 54598 | 6 其实a自己就是java的成功典范
也不需要看netflix | z****e
发帖数: 54598 | 7 升级维护成本这些，失败的例子
节选自programming某人的文章
目前为止我所知道的比较大规模的应用就是Scala一两年前在Yammer，那是个彻底的失
败，主要原因就是语言和核心库变动剧烈，多种paradigm并存不只是对应用层面造成问
题，在库的层面的问题远远超过了普通Scala程序员的水平，学习成本高，系统维护费
用高。所以Yammer一年后转回了Java | p*****2
发帖数: 21240 | 8
java还真不适合startup
【在 z****e 的大作中提到】
: 升级维护成本这些，失败的例子
: 节选自programming某人的文章
: 目前为止我所知道的比较大规模的应用就是Scala一两年前在Yammer，那是个彻底的失
: 败，主要原因就是语言和核心库变动剧烈，多种paradigm并存不只是对应用层面造成问
: 题，在库的层面的问题远远超过了普通Scala程序员的水平，学习成本高，系统维护费
: 用高。所以Yammer一年后转回了Java
| z****e
发帖数: 54598 | 9 看面官怎么说
就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
基本属于暴兵流, 每个instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
别多的instance.
嗯
【在 p*****2 的大作中提到】
:
: java还真不适合startup
| z****e
发帖数: 54598 | 10 问个题外的，暴兵流英语怎么说？
还是你看了公孙大神的文章，借用的？
,
【在 e******0 的大作中提到】
: open question:
: 假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越好,比如前期成
: 本,开发维护, 后面如何方便升级, scale up等等... as much as you know
: 我看板上大牛们常常讨论这个的样子, 不明觉厉, 但是我等菜鸟实在缺乏经验, 大牛们
: 讨论的我能看懂的也不多.只知道几个比较传统老旧的比如LAMP之类的还有就是自己有
: 过经验的, 高端大气上档次点的比如如何scale, nosql之类等等我没用过也是白扯.
: 当时扯了扯自己会的, 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
: 基本属于暴兵流(就是人海战术的意思,不求个体的质量, 只以总量取胜), 每个
: instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
: 别多的instance. 当然再细究他们怎么做到这么多instance的协作的时候,又成小白了,
| | | p*****2
发帖数: 21240 | 11
面试确实看面试官。对了，顺便问大牛一个问题。
cache layer是不是一般在RMDBS里是个必要。NOSQL的话，是不是cache不是一个必需品
了？当然也要看app需求了。
【在 z****e 的大作中提到】
: 看面官怎么说
: 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
: 基本属于暴兵流, 每个instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
: 别多的instance.
: 嗯
| z****e
发帖数: 54598 | 12 其实我觉得，我们用storm本身就可以算作一个cache了
rmdbs里面一般自带有cache，你每一次sql执行之后的结果都会被一定程度滴cache起来
nosql也要看具体产品，mongodb这种接近传统db的奇芭估计自带有cache
其它就不好说了，这种东西如果不是因为效率明显被拉下来
不会刻意自己去实现cache吧？
【在 p*****2 的大作中提到】
:
: 面试确实看面试官。对了，顺便问大牛一个问题。
: cache layer是不是一般在RMDBS里是个必要。NOSQL的话，是不是cache不是一个必需品
: 了？当然也要看app需求了。
| e******0
发帖数: 291 | 13 对的, 英文我不知道, 我回来准备恶补这块东西, 跑去翻你们的帖子, 发现暴兵流这个
词实在是贴切
【在 z****e 的大作中提到】
: 问个题外的，暴兵流英语怎么说？
: 还是你看了公孙大神的文章，借用的？
:
: ,
| l****o
发帖数: 315 | 14 既然暴兵流了，大家都打星际么，要不要组织起来打几把。 | l*n
发帖数: 529 | 15 无聊搜了一下，看来是即时战略的某种打法，大概是没有对应的正式英语词汇的。
【在 z****e 的大作中提到】
: 问个题外的，暴兵流英语怎么说？
: 还是你看了公孙大神的文章，借用的？
:
: ,
| z****e
发帖数: 54598 | 16 很可惜，之前问过了，公孙大神不玩游戏
【在 l****o 的大作中提到】
: 既然暴兵流了，大家都打星际么，要不要组织起来打几把。
| s********u
发帖数: 1109 | 17 spam.比如暴追猎：stalker spam
zhaoce大神也打星际2么
【在 z****e 的大作中提到】
: 问个题外的，暴兵流英语怎么说？
: 还是你看了公孙大神的文章，借用的？
:
: ,
| d***n
发帖数: 832 | 18 如果是startup，首先选个云平台来host，这个非常重要
frontend可以考虑用php, node.js, asp.net 和 java
哪个快上哪个，很大程度取决于初创人员的水平和偏好
每个frontend instance都是独立的，前面再加上load balancer
每个frontend可以有自己的cache
中间这一层可以说是api层或business logic层
如果是RESTful API，有多种语言选择都可以，关键要找个成熟的framework来支持
中间这一层双可以分两小层 api frontend和worker(异步处理用)
后面基本是用nosql了，基本上选了云平台这个也定了
当然云平台的选择也基于多个因素的
cache呢一般云平台都会提供这方面的服务
messenging也是 | z****e
发帖数: 54598 | 19 偶尔也玩，不过玩得很烂，基本上都是被虐
【在 s********u 的大作中提到】
: spam.比如暴追猎：stalker spam
: zhaoce大神也打星际2么
| e******0
发帖数: 291 | 20 最后提到的那个cache是类似于JVM里的Java cache system的那种cache吗? 木有用过,
我只是面试的时候听面馆说了他们用这个和数据库混搭着用
【在 d***n 的大作中提到】
: 如果是startup，首先选个云平台来host，这个非常重要
: frontend可以考虑用php, node.js, asp.net 和 java
: 哪个快上哪个，很大程度取决于初创人员的水平和偏好
: 每个frontend instance都是独立的，前面再加上load balancer
: 每个frontend可以有自己的cache
: 中间这一层可以说是api层或business logic层
: 如果是RESTful API，有多种语言选择都可以，关键要找个成熟的framework来支持
: 中间这一层双可以分两小层 api frontend和worker(异步处理用)
: 后面基本是用nosql了，基本上选了云平台这个也定了
: 当然云平台的选择也基于多个因素的
| | | e********3
发帖数: 229 | | e******0
发帖数: 291 | 22 我忘记是在JAVA版还是programming版看到的了,好像还是goodbug和公孙掐架的一个帖子
【在 e********3 的大作中提到】
: 求公孙大神文章链接！！
| x******a
发帖数: 11 | 23 PHP + MemCache/HBase + MySQL | p*****2
发帖数: 21240 | 24
你是说memcache或者hbase吗？
【在 x******a 的大作中提到】
: PHP + MemCache/HBase + MySQL
| a****a
发帖数: 37 | 25 新手学习，写了一些，请各位大牛给指点一下。谢谢！
1) basic architecture:
front end == > pick a web development framework, need to consider both
client side + server side app development: ajax), code review: scan for
security vulnerabilities
back end ==> pick persistent layer (database: SQL vs no SQL; Blob storage);
2) scalability, performance, fault tolerant
design considerations: stateless application, push states to persistent
layer
allow easy load balancing and failure handling (load balancer ahead of web
tier)
handling static content read: caching, can use application layer cache such
as memcache)
handling dynamic content: build appropriate indexing structure to speed up
search/query (may requires back end data processing, mapreduce jobs etc)
scaling and FT of data layer: CAP theorem, NoSQL stuff...
3) maintenance:
- handling dynamic traffic: allowing autoscaling
- handling failure
Solution:use cloud service, [key idea is to have a monitoring service to
monitor the performance/liveness of the system, make configuration changes
dynamically]
- adding new features:
testing driven development
push for deployment, allow system roll back, if there is any problem... | e******0
发帖数: 291 | 26 open question:
假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越好,比如前期成
本,开发维护, 后面如何方便升级, scale up等等... as much as you know
我看板上大牛们常常讨论这个的样子, 不明觉厉, 但是我等菜鸟实在缺乏经验, 大牛们
讨论的我能看懂的也不多.只知道几个比较传统老旧的比如LAMP之类的还有就是自己有
过经验的, 高端大气上档次点的比如如何scale, nosql之类等等我没用过也是白扯.
当时扯了扯自己会的, 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
基本属于暴兵流(就是人海战术的意思,不求个体的质量, 只以总量取胜), 每个
instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
别多的instance. 当然再细究他们怎么做到这么多instance的协作的时候,又成小白了,
大牛们指点下迷津吧, 说实话我觉得这些东
西真的是太需要实际经验了,亚麻那个面试官年纪轻轻的, 我觉得他也就懂他们系统里
那一套, 我搬了点大牛们常在版上讨论的名词出来, 他也不懂. | l****o
发帖数: 315 | 27 我去。。。你是new grad吗？ 感觉当年我要被面了这个可能就拿不到offer了。 | e******0
发帖数: 291 | 28 只能说, 不算是....
【在 l****o 的大作中提到】
: 我去。。。你是new grad吗？ 感觉当年我要被面了这个可能就拿不到offer了。
| p*****2
发帖数: 21240 | | z****e
发帖数: 54598 | 30
这种问题，无脑上java，维护成本，升级，scale up这些参考netflix
,
【在 e******0 的大作中提到】
: open question:
: 假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越好,比如前期成
: 本,开发维护, 后面如何方便升级, scale up等等... as much as you know
: 我看板上大牛们常常讨论这个的样子, 不明觉厉, 但是我等菜鸟实在缺乏经验, 大牛们
: 讨论的我能看懂的也不多.只知道几个比较传统老旧的比如LAMP之类的还有就是自己有
: 过经验的, 高端大气上档次点的比如如何scale, nosql之类等等我没用过也是白扯.
: 当时扯了扯自己会的, 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
: 基本属于暴兵流(就是人海战术的意思,不求个体的质量, 只以总量取胜), 每个
: instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
: 别多的instance. 当然再细究他们怎么做到这么多instance的协作的时候,又成小白了,
| | | z****e
发帖数: 54598 | 31 其实a自己就是java的成功典范
也不需要看netflix | z****e
发帖数: 54598 | 32 升级维护成本这些，失败的例子
节选自programming某人的文章
目前为止我所知道的比较大规模的应用就是Scala一两年前在Yammer，那是个彻底的失
败，主要原因就是语言和核心库变动剧烈，多种paradigm并存不只是对应用层面造成问
题，在库的层面的问题远远超过了普通Scala程序员的水平，学习成本高，系统维护费
用高。所以Yammer一年后转回了Java | p*****2
发帖数: 21240 | 33
java还真不适合startup
【在 z****e 的大作中提到】
: 升级维护成本这些，失败的例子
: 节选自programming某人的文章
: 目前为止我所知道的比较大规模的应用就是Scala一两年前在Yammer，那是个彻底的失
: 败，主要原因就是语言和核心库变动剧烈，多种paradigm并存不只是对应用层面造成问
: 题，在库的层面的问题远远超过了普通Scala程序员的水平，学习成本高，系统维护费
: 用高。所以Yammer一年后转回了Java
| z****e
发帖数: 54598 | 34 看面官怎么说
就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
基本属于暴兵流, 每个instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
别多的instance.
嗯
【在 p*****2 的大作中提到】
:
: java还真不适合startup
| z****e
发帖数: 54598 | 35 问个题外的，暴兵流英语怎么说？
还是你看了公孙大神的文章，借用的？
,
【在 e******0 的大作中提到】
: open question:
: 假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越好,比如前期成
: 本,开发维护, 后面如何方便升级, scale up等等... as much as you know
: 我看板上大牛们常常讨论这个的样子, 不明觉厉, 但是我等菜鸟实在缺乏经验, 大牛们
: 讨论的我能看懂的也不多.只知道几个比较传统老旧的比如LAMP之类的还有就是自己有
: 过经验的, 高端大气上档次点的比如如何scale, nosql之类等等我没用过也是白扯.
: 当时扯了扯自己会的, 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
: 基本属于暴兵流(就是人海战术的意思,不求个体的质量, 只以总量取胜), 每个
: instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
: 别多的instance. 当然再细究他们怎么做到这么多instance的协作的时候,又成小白了,
| p*****2
发帖数: 21240 | 36
面试确实看面试官。对了，顺便问大牛一个问题。
cache layer是不是一般在RMDBS里是个必要。NOSQL的话，是不是cache不是一个必需品
了？当然也要看app需求了。
【在 z****e 的大作中提到】
: 看面官怎么说
: 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
: 基本属于暴兵流, 每个instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
: 别多的instance.
: 嗯
| z****e
发帖数: 54598 | 37 其实我觉得，我们用storm本身就可以算作一个cache了
rmdbs里面一般自带有cache，你每一次sql执行之后的结果都会被一定程度滴cache起来
nosql也要看具体产品，mongodb这种接近传统db的奇芭估计自带有cache
其它就不好说了，这种东西如果不是因为效率明显被拉下来
不会刻意自己去实现cache吧？
【在 p*****2 的大作中提到】
:
: 面试确实看面试官。对了，顺便问大牛一个问题。
: cache layer是不是一般在RMDBS里是个必要。NOSQL的话，是不是cache不是一个必需品
: 了？当然也要看app需求了。
| e******0
发帖数: 291 | 38 对的, 英文我不知道, 我回来准备恶补这块东西, 跑去翻你们的帖子, 发现暴兵流这个
词实在是贴切
【在 z****e 的大作中提到】
: 问个题外的，暴兵流英语怎么说？
: 还是你看了公孙大神的文章，借用的？
:
: ,
| l****o
发帖数: 315 | 39 既然暴兵流了，大家都打星际么，要不要组织起来打几把。 | l*n
发帖数: 529 | 40 无聊搜了一下，看来是即时战略的某种打法，大概是没有对应的正式英语词汇的。
【在 z****e 的大作中提到】
: 问个题外的，暴兵流英语怎么说？
: 还是你看了公孙大神的文章，借用的？
:
: ,
| | | z****e
发帖数: 54598 | 41 很可惜，之前问过了，公孙大神不玩游戏
【在 l****o 的大作中提到】
: 既然暴兵流了，大家都打星际么，要不要组织起来打几把。
| s********u
发帖数: 1109 | 42 spam.比如暴追猎：stalker spam
zhaoce大神也打星际2么
【在 z****e 的大作中提到】
: 问个题外的，暴兵流英语怎么说？
: 还是你看了公孙大神的文章，借用的？
:
: ,
| d***n
发帖数: 832 | 43 如果是startup，首先选个云平台来host，这个非常重要
frontend可以考虑用php, node.js, asp.net 和 java
哪个快上哪个，很大程度取决于初创人员的水平和偏好
每个frontend instance都是独立的，前面再加上load balancer
每个frontend可以有自己的cache
中间这一层可以说是api层或business logic层
如果是RESTful API，有多种语言选择都可以，关键要找个成熟的framework来支持
中间这一层双可以分两小层 api frontend和worker(异步处理用)
后面基本是用nosql了，基本上选了云平台这个也定了
当然云平台的选择也基于多个因素的
cache呢一般云平台都会提供这方面的服务
messenging也是 | z****e
发帖数: 54598 | 44 偶尔也玩，不过玩得很烂，基本上都是被虐
【在 s********u 的大作中提到】
: spam.比如暴追猎：stalker spam
: zhaoce大神也打星际2么
| e******0
发帖数: 291 | 45 最后提到的那个cache是类似于JVM里的Java cache system的那种cache吗? 木有用过,
我只是面试的时候听面馆说了他们用这个和数据库混搭着用
【在 d***n 的大作中提到】
: 如果是startup，首先选个云平台来host，这个非常重要
: frontend可以考虑用php, node.js, asp.net 和 java
: 哪个快上哪个，很大程度取决于初创人员的水平和偏好
: 每个frontend instance都是独立的，前面再加上load balancer
: 每个frontend可以有自己的cache
: 中间这一层可以说是api层或business logic层
: 如果是RESTful API，有多种语言选择都可以，关键要找个成熟的framework来支持
: 中间这一层双可以分两小层 api frontend和worker(异步处理用)
: 后面基本是用nosql了，基本上选了云平台这个也定了
: 当然云平台的选择也基于多个因素的
| e********3
发帖数: 229 | | e******0
发帖数: 291 | 47 我忘记是在JAVA版还是programming版看到的了,好像还是goodbug和公孙掐架的一个帖子
【在 e********3 的大作中提到】
: 求公孙大神文章链接！！
| x******a
发帖数: 11 | 48 PHP + MemCache/HBase + MySQL | p*****2
发帖数: 21240 | 49
你是说memcache或者hbase吗？
【在 x******a 的大作中提到】
: PHP + MemCache/HBase + MySQL
| a****a
发帖数: 37 | 50 新手学习，写了一些，请各位大牛给指点一下。谢谢！
1) basic architecture:
front end == > pick a web development framework, need to consider both
client side + server side app development: ajax), code review: scan for
security vulnerabilities
back end ==> pick persistent layer (database: SQL vs no SQL; Blob storage);
2) scalability, performance, fault tolerant
design considerations: stateless application, push states to persistent
layer
allow easy load balancing and failure handling (load balancer ahead of web
tier)
handling static content read: caching, can use application layer cache such
as memcache)
handling dynamic content: build appropriate indexing structure to speed up
search/query (may requires back end data processing, mapreduce jobs etc)
scaling and FT of data layer: CAP theorem, NoSQL stuff...
3) maintenance:
- handling dynamic traffic: allowing autoscaling
- handling failure
Solution:use cloud service, [key idea is to have a monitoring service to
monitor the performance/liveness of the system, make configuration changes
dynamically]
- adding new features:
testing driven development
push for deployment, allow system roll back, if there is any problem... | | | m*******m
发帖数: 80 | 51 对于初学者很有帮助,谢谢啦~~~
);
【在 a****a 的大作中提到】
: 新手学习，写了一些，请各位大牛给指点一下。谢谢！
: 1) basic architecture:
: front end == > pick a web development framework, need to consider both
: client side + server side app development: ajax), code review: scan for
: security vulnerabilities
: back end ==> pick persistent layer (database: SQL vs no SQL; Blob storage);
: 2) scalability, performance, fault tolerant
: design considerations: stateless application, push states to persistent
: layer
: allow easy load balancing and failure handling (load balancer ahead of web
| l*******g
发帖数: 82 | 52
open question:假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越
好,比如前期成本,开发维护, 后面如何方便升级, scale up等等..........
你可以看看amzon最近的关于他们s3系统的设计，不过至于你问的那个这么多instanse
如何协同，其实简单地来讲就是要做到http session的 cluster，或者是叫
replication，也就是说，用户的访问session，在任何一个instanse上可以立刻复原，
他们基本用s3来做session的persistence layer，不过我怀疑他们也用nosql的
memcached之类的做了缓存。
amazon要是问我这种设计题就好了，上次下班后电面还问算法！哎。
【在 e******0 的大作中提到】
: open question:
: 假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越好,比如前期成
: 本,开发维护, 后面如何方便升级, scale up等等... as much as you know
: 我看板上大牛们常常讨论这个的样子, 不明觉厉, 但是我等菜鸟实在缺乏经验, 大牛们
: 讨论的我能看懂的也不多.只知道几个比较传统老旧的比如LAMP之类的还有就是自己有
: 过经验的, 高端大气上档次点的比如如何scale, nosql之类等等我没用过也是白扯.
: 当时扯了扯自己会的, 就去反问他们亚麻的系统是怎么样的, 他说他们全是开源,
: 基本属于暴兵流(就是人海战术的意思,不求个体的质量, 只以总量取胜), 每个
: instance算不上高档, tomcat加nosql+RMDBS+cache, 但是有特
: 别多的instance. 当然再细究他们怎么做到这么多instance的协作的时候,又成小白了,
| e******0
发帖数: 291 | 53
instanse
【在 l*******g 的大作中提到】
:
: open question:假设你现在要开个web相关的startup,请设计一个系统,考虑的越周全越
: 好,比如前期成本,开发维护, 后面如何方便升级, scale up等等..........
: 你可以看看amzon最近的关于他们s3系统的设计，不过至于你问的那个这么多instanse
: 如何协同，其实简单地来讲就是要做到http session的 cluster，或者是叫
: replication，也就是说，用户的访问session，在任何一个instanse上可以立刻复原，
: 他们基本用s3来做session的persistence layer，不过我怀疑他们也用nosql的
: memcached之类的做了缓存。
: amazon要是问我这种设计题就好了，上次下班后电面还问算法！哎。
| m********7
发帖数: 1368 | 54 公孙大神指的是 danielfeng ？
帖子
【在 e******0 的大作中提到】
: 我忘记是在JAVA版还是programming版看到的了,好像还是goodbug和公孙掐架的一个帖子
| d*******h
发帖数: 642 | 55 前端还可以再加个反向代理，比如varnish之类的content cache，放在web server的
load balancer前面
);
【在 a****a 的大作中提到】
: 新手学习，写了一些，请各位大牛给指点一下。谢谢！
: 1) basic architecture:
: front end == > pick a web development framework, need to consider both
: client side + server side app development: ajax), code review: scan for
: security vulnerabilities
: back end ==> pick persistent layer (database: SQL vs no SQL; Blob storage);
: 2) scalability, performance, fault tolerant
: design considerations: stateless application, push states to persistent
: layer
: allow easy load balancing and failure handling (load balancer ahead of web
|
|
