s****y
发帖数: 503 | 1 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
Tomcat、MySql组成后台服务器，中间用Web Service相连接。
像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？ |
p*****2
发帖数: 21240 | 2 是 小公司mean就够了
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
|
s****y
发帖数: 503 | |
g*****g
发帖数: 34805 | 4 几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
势很大。
性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
常发生。
就个人经验而言，当一个项目需要超过10个人参与，就应该分了。 |
w**z
发帖数: 8232 | 5 你们 web service 用 Jersey, webserver 用什么？
【在 g*****g 的大作中提到】
: 几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
: 势很大。
: 性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
: 范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
: 个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
: feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
: 常发生。
: 就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
|
g*****g
发帖数: 34805 | 6 tomcat.
【在 w**z 的大作中提到】
: 你们 web service 用 Jersey, webserver 用什么？
|
c*********e
发帖数: 16335 | 7 web services要买ssl,有的公司为了省这个钱，不用web services,用其它的办法。
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
|
D*****r
发帖数: 6791 | 8 SOA数据库访问是不是一般又必须设计高响应的网络
加复杂的cache体系，否则会慢的哭。
【在 g*****g 的大作中提到】
: 几乎每个项目大了都这么用，项目大了必须SOA是共识。前端技术竞争激烈，后端JVM优
: 势很大。
: 性能其实不是最主要的考虑，而是separation，当一个项目大到超出了一个team的管理
: 范围，就开始出现两个大问题，一是产品出了问题没有人什么都懂，debug过程会在几
: 个team来回，问题解决得慢。二是所有的release要一起进行，一个team弄了个大
: feature没问题却不得不因为另一个team的一个bug rollback，结果就是release延期经
: 常发生。
: 就个人经验而言，当一个项目需要超过10个人参与，就应该分了。
|
w**z
发帖数: 8232 | 9 你们的ws 分内部和公开的吗？ 内部访问的就不用authentication了？
【在 g*****g 的大作中提到】
: tomcat.
|
s****y
发帖数: 503 | 10
怎么买SSL（Secure Sockets Layer）？
【在 c*********e 的大作中提到】
: web services要买ssl,有的公司为了省这个钱，不用web services,用其它的办法。
|
|
|
w**z
发帖数: 8232 | 11 根据domain 买个 signed certificate 装在Web server 上。要不browser 就报waning.
【在 s****y 的大作中提到】
:
: 怎么买SSL（Secure Sockets Layer）？
|
l********s
发帖数: 358 | 12 PayPal的架构是，Dust.js/Backbone.js/Node.js + RESTful services (Java or
Scala). |
g*****g
发帖数: 34805 | 13 内部不用验证，直接Eureka做mid tier load balancing. 只有个别服务有对外的WS，
验证应该跟网站类似。
【在 w**z 的大作中提到】
: 你们的ws 分内部和公开的吗？ 内部访问的就不用authentication了？
|
g*****g
发帖数: 34805 | 14 不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
.9%的
availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
circuit breaker, graceful degradation的问题都要考虑。
【在 D*****r 的大作中提到】
: SOA数据库访问是不是一般又必须设计高响应的网络
: 加复杂的cache体系，否则会慢的哭。
|
w**z
发帖数: 8232 | 15 就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
ation service down 了， 搞个static list 糊弄一下你。
99
【在 g*****g 的大作中提到】
: 不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
: .9%的
: availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
: circuit breaker, graceful degradation的问题都要考虑。
|
p*****2
发帖数: 21240 | 16 我觉得是 所以其实挺麻烦的
【在 w**z 的大作中提到】
: 就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
: ation service down 了， 搞个static list 糊弄一下你。
:
: 99
|
w**z
发帖数: 8232 | 17 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
code 同时run, 如何切换，如何 rollback, 确实不容易。
【在 p*****2 的大作中提到】
: 我觉得是 所以其实挺麻烦的
|
p*****2
发帖数: 21240 | 18 这也是challenge和经验呀
所以要像你们这些大牛学习了
感觉半海这方面是专家
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
|
y**********u
发帖数: 6366 | 19 其实我觉得小公司基本上不太需要有后端开发
【在 s****y 的大作中提到】
: 上次有个帖子好像讨论了淘宝UED的《前后端分离的思考与实践》，讲前台服务器和后
: 台服务器分离的架构。 比如用Node.js、Backbone.js、Bootstrap组成前台服务器，用
: Tomcat、MySql组成后台服务器，中间用Web Service相连接。
: 像这样的架构现在用的多吗？是不是只有大公司性能要求高的网站才这么用？
|
g*****g
发帖数: 34805 | 20 其实没有那么难，有问题，就会有人去做轮子，有规范化的设计模式，说到底都是经验
而已。
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
|
|
|
c*********e
发帖数: 16335 | 21 外面的网站能调用公司内部的web services吗？
【在 g*****g 的大作中提到】
: 内部不用验证，直接Eureka做mid tier load balancing. 只有个别服务有对外的WS，
: 验证应该跟网站类似。
|
c*********e
发帖数: 16335 | 22 那不就相当于redirect到400,500 error page了吗？自己搞一个static list 放error
page上，看着象没有error一样？
【在 w**z 的大作中提到】
: 就是说任何一个service down,都尽量不要让用户察觉到。 比如说他家的recommend
: ation service down 了， 搞个static list 糊弄一下你。
:
: 99
|
c*********e
发帖数: 16335 | 23 goodbug到底在netflix做java programming还是network administration的阿？
【在 g*****g 的大作中提到】
: 其实没有那么难，有问题，就会有人去做轮子，有规范化的设计模式，说到底都是经验
: 而已。
|
w**z
发帖数: 8232 | 24 比这复杂。一个页面，可能要。调用几十个service。 一个error page 哪行啊。
error
【在 c*********e 的大作中提到】
: 那不就相当于redirect到400,500 error page了吗？自己搞一个static list 放error
: page上，看着象没有error一样？
|
z****e
发帖数: 54598 | 25 扯
我工作过的小公司哪怕只有20多个人
都有前后端分离
他们用的是php+spring
【在 y**********u 的大作中提到】
: 其实我觉得小公司基本上不太需要有后端开发
|
D*****r
发帖数: 6791 | 26 有道理，这种软处理的high availability很有意思。我原来一想到HA，就想到一个
daemon进程盯着、进程死了就重新启一下，或者热备一个系统、VRRP什么的热备份一个
，系统复杂了很多，工行2014年7月16日银证系统网络设备故障，热备系统切换期间出
现单边交账，这种很容易出问题。
circuit breaker\graceful degradation能让系统健壮很多，而且也不会造成复杂度爆
炸。
并行异步处理，可能对reddit这种小条目的架构能做到惊人的吞吐量，关键服务的数据
库的处理如果用这个，感觉还是危险。
99
【在 g*****g 的大作中提到】
: 不需要高相应的网络，需要高availability和尽量异步并行的服务。如果一个服务有99
: .9%的
: availability，一个request过10个服务就剩99%。所以如果在critical path上，各种
: circuit breaker, graceful degradation的问题都要考虑。
|
D*****r
发帖数: 6791 | 27 据说他家做了chaos monkey，专门随机搞死一个个的节点，来测稳定性……
多个版本的可以对应请求把版本号带上，比如用发布日期做版本号。
【在 w**z 的大作中提到】
: 是啊，如果是几十，上百的 service,那是相当复杂。 而且是在cloud 里， 任何时间
: ，任何node都有可能挂。在想想deploy 新code 的时候，同一个service 有两个版本的
: code 同时run, 如何切换，如何 rollback, 确实不容易。
|
g*****g
发帖数: 34805 | 28 大多数网站，主页面可能过几十个服务，但不过是读而已，很多服务之间也没有顺序的
要求。所以异步并行是可能的。
Ajax的本质如此。
【在 D*****r 的大作中提到】
: 有道理，这种软处理的high availability很有意思。我原来一想到HA，就想到一个
: daemon进程盯着、进程死了就重新启一下，或者热备一个系统、VRRP什么的热备份一个
: ，系统复杂了很多，工行2014年7月16日银证系统网络设备故障，热备系统切换期间出
: 现单边交账，这种很容易出问题。
: circuit breaker\graceful degradation能让系统健壮很多，而且也不会造成复杂度爆
: 炸。
: 并行异步处理，可能对reddit这种小条目的架构能做到惊人的吞吐量，关键服务的数据
: 库的处理如果用这个，感觉还是危险。
:
: 99
|
w**z
发帖数: 8232 | 29 听说它们不止搞死节点，还搞死AZ， 甚至整个region 做测试。
【在 D*****r 的大作中提到】
: 据说他家做了chaos monkey，专门随机搞死一个个的节点，来测稳定性……
: 多个版本的可以对应请求把版本号带上，比如用发布日期做版本号。
|
z****e
发帖数: 54598 | 30 这样好，可以有效减少on call次数
【在 w**z 的大作中提到】
: 听说它们不止搞死节点，还搞死AZ， 甚至整个region 做测试。
|
|
|
c*******0
发帖数: 5247 | 31
您接触的小公司或者数量不够，或者类型单一。
【在 y**********u 的大作中提到】
: 其实我觉得小公司基本上不太需要有后端开发
|
