z*******a
发帖数: 858 | 1 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
了：毕竟积累太少太差，如果技术有错，大伙轻拍。
先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
随时rollback，这个真的非常强大。
所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
环境了……听起来很吓人，但是实际操作中会发现，的确没什么大不了的。真正引发大
问题的很多是SDE的误操作，改了数据库然后才有灾难，Code本身很难引发什么真正的
问题。
所以这里想说的是，亚马逊基本上是SDE在test（也只是很简单的test），只需要很少
的SDET。尤其是没有对外的界面、backend的组。
这的确是亚马逊强大的基础之一：首先省了很多雇佣tester的钱，其次是提高了生产效
率，如果想的话code可以很快（一天之内，很多紧急修复）deploy到全世界范围；第三
是即使SDE缺乏经验、经常出错或是没考虑到某些case也不要紧，反正一发现错误
rollback就是。当然，SOA是以上一切的基础，否则都是空谈。
所以亚马逊不在乎员工流失。当然，问题不那么简单：code好写，business logic却非
常复杂，新人就不理解了。举个例子，亚马逊效率很高，实现很快，但是可能应用后很
快发现这business logic有问题，或是跟别的组没有协调好，所以只能再改再重写，而
当时写老code的人都走了，所以新人只能再重新猜究竟是怎样的。这就导致了：亚马逊
的code更新很快，服务很强大也及时，但是其实SDE是很遭罪的，因为毕竟归根结底，
质量还是不行的。
简而言之，亚马逊的开发平台相当先进，使得他可以用缺少经验的程序员维护一个庞大
而高效的系统，从而造成了亚马逊独特的公司文化。 |
b***m
发帖数: 5987 | 2 微软其实在部分地这么学了。以我所在的项目，极少的PM，大量的SDE，几乎没有SDET
。只是deploy还是需要通过专门的OP team，不允许SDE做。 |
h*****a
发帖数: 1718 | 3 build-deployment的pipeline现在几个主要公司都有自己的solution，open source也
有非常完整的解决方案。A的Brazil + Apollo确实有它的很大先进性，但也有几个重要
的limitation。随便说两个，不见得对：
1）A的方案中，对package dependency的管理是通过建立snapshot来固定的，这样是很
方便解决conflict的问题，但对于有些公司需要永远用最新的package version（比如G
)，就不见的实用。所以G是永远全部从source build，和A走了完全不同的path。
2）Apollo的deployment全程有central service来协调控制，这样做到了非常好的对
deployment的监控和reporting。但这事实上造成了central service成为bottleneck。
记得几年前当有很大规模的deployment in progress的时候，其它的deployment有可能
要等很久。不知道这种情况现在是否有改善。
3) 不知道现在Apollo对在EC2上做deployment的支持怎样了，至少前几年支持还不够好
。现在很多中小公司把service建立在EC2上，以Netflix为最。Netflix已经实现了非常
完备的在EC2上从build到deployment，包括Red-Black testing的整个pipeline的解决
方案，而且都已经open source。这实际上成也为了对AWS的重大补充和提高。
所以说想用Apollo来打包卖钱基本上是不现实的，呵呵，因为其实open source已经有
了非常成熟的free的solution。当然, Amazon的solution还是非常先进的。
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
r********d
发帖数: 7742 | 4 嗯，赞，学习了。
大伙接着聊，我们好做笔记。
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
d********g
发帖数: 10550 | 5 这不是老早就已经是业界标准了吗？
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
r********d
发帖数: 7742 | 6 跟这个配图最褡的回复就是
“公孙欠扁”。lol
【在 d********g 的大作中提到】
: 这不是老早就已经是业界标准了吗？
:
: version
: 有组
: deploy
: test
|
h***i
发帖数: 1970 | 7 这个图有年头了
【在 d********g 的大作中提到】
: 这不是老早就已经是业界标准了吗？
:
: version
: 有组
: deploy
: test
|
c******a
发帖数: 789 | 8 太牛b了
如G
赞！记下了！
这么不scalable？
【在 h*****a 的大作中提到】
: build-deployment的pipeline现在几个主要公司都有自己的solution，open source也
: 有非常完整的解决方案。A的Brazil + Apollo确实有它的很大先进性，但也有几个重要
: 的limitation。随便说两个，不见得对：
: 1）A的方案中，对package dependency的管理是通过建立snapshot来固定的，这样是很
: 方便解决conflict的问题，但对于有些公司需要永远用最新的package version（比如G
: )，就不见的实用。所以G是永远全部从source build，和A走了完全不同的path。
: 2）Apollo的deployment全程有central service来协调控制，这样做到了非常好的对
: deployment的监控和reporting。但这事实上造成了central service成为bottleneck。
: 记得几年前当有很大规模的deployment in progress的时候，其它的deployment有可能
: 要等很久。不知道这种情况现在是否有改善。
|
h*****a
发帖数: 1718 | 9 谈不上不scalable，这完全要看具体的use case。一般来说一个service的instance 数
目不会太多。如果没有上到几千这个量级不会造成什么问题。而且我说的情况现在可能
已经有提高了。
【在 c******a 的大作中提到】
: 太牛b了
:
: 如G
: 赞！记下了！
: 这么不scalable？
|
f*******t
发帖数: 7549 | 10 可能你离开A时间太长了，这些问题已经被修复。
1.如果你愿意，可以自动merge from live，对pipeline test有信心的话除了特定的几
个package，其它都可以设定为实时更新。
2.现在deployment system的性能没看到过瓶颈问题。但它挂掉时所有组都不能deploy
，有可能导致严重问题，这是centralized system必然缺陷。
3.A已逐步淘汰老式服务器，新service一般都放到EC2上。apollo auto scaling做的还
不错，也已商用。
如G
【在 h*****a 的大作中提到】
: build-deployment的pipeline现在几个主要公司都有自己的solution，open source也
: 有非常完整的解决方案。A的Brazil + Apollo确实有它的很大先进性，但也有几个重要
: 的limitation。随便说两个，不见得对：
: 1）A的方案中，对package dependency的管理是通过建立snapshot来固定的，这样是很
: 方便解决conflict的问题，但对于有些公司需要永远用最新的package version（比如G
: )，就不见的实用。所以G是永远全部从source build，和A走了完全不同的path。
: 2）Apollo的deployment全程有central service来协调控制，这样做到了非常好的对
: deployment的监控和reporting。但这事实上造成了central service成为bottleneck。
: 记得几年前当有很大规模的deployment in progress的时候，其它的deployment有可能
: 要等很久。不知道这种情况现在是否有改善。
|
|
|
h*****a
发帖数: 1718 | 11 印象里不是每个team每次change都在live里面build的。如果dependency在live里面还
没有build好那会很大的延长build的时间。而且也可能会引入很多dependency
conflicts.
deploy
Well，性能瓶颈不是经常能观察到的。我相信在它成为问题之后Apollo会给出一定的解
决方案。但这种通过central service监控的design是有fondamental的limitation的，
你无法想象用Apollo给整个EC2 fleet（数十万台机器？）做deployment，呵呵。
我已经强调过，A的solution很先进，但有它适用的use case.
deploy |
l*****t
发帖数: 2019 | 12 真不懂这个CI/CD有什么好说事儿的。大部分end user facing 的公司都有这个。
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
z*******a
发帖数: 858 | 13 说的不是continuous，那个当然简单。
【在 l*****t 的大作中提到】
: 真不懂这个CI/CD有什么好说事儿的。大部分end user facing 的公司都有这个。
:
: version
: 有组
: deploy
: test
|
l******g
发帖数: 366 | 14 ci/cd的idea都很简单，但人多了以后还能保持高效是非常非常难的。
【在 l*****t 的大作中提到】
: 真不懂这个CI/CD有什么好说事儿的。大部分end user facing 的公司都有这个。
:
: version
: 有组
: deploy
: test
|
P**l
发帖数: 3722 | 15 lz哪个组啊？deploy之前不test？不是tier-1 service吧。。 |
T*U
发帖数: 22634 | 16 service 是 read only 吧
【在 P**l 的大作中提到】
: lz哪个组啊？deploy之前不test？不是tier-1 service吧。。
|
p**********e
发帖数: 316 | 17 A能做到100% SOA, 这样模块之间， 不同部门之间的coupling就减少很多，这个系统相
对来说更容易实现.
如G
【在 h*****a 的大作中提到】
: build-deployment的pipeline现在几个主要公司都有自己的solution，open source也
: 有非常完整的解决方案。A的Brazil + Apollo确实有它的很大先进性，但也有几个重要
: 的limitation。随便说两个，不见得对：
: 1）A的方案中，对package dependency的管理是通过建立snapshot来固定的，这样是很
: 方便解决conflict的问题，但对于有些公司需要永远用最新的package version（比如G
: )，就不见的实用。所以G是永远全部从source build，和A走了完全不同的path。
: 2）Apollo的deployment全程有central service来协调控制，这样做到了非常好的对
: deployment的监控和reporting。但这事实上造成了central service成为bottleneck。
: 记得几年前当有很大规模的deployment in progress的时候，其它的deployment有可能
: 要等很久。不知道这种情况现在是否有改善。
|
r****s
发帖数: 1025 | 18 我只想草Apollo和Brazil。老子在的时候，build一次要半小时以上，愚蠢到死。
我怀疑这帮孙子每次都临时scp dependency package,尼玛local build只要10秒钟，
submit一个build到完成居然要40分钟。这JB玩意居然商用了。
在version set 里resolve conflicts 还是尼玛人工一个一个package地挑出来。
build 这个过程里99%的工作由javac,也就是Sun搞定了，你也就做一个1%的文件管理的
工作量，卧槽还搞得这么复杂。
我老人家离开亚麻的一小部分原因，也是这个build system实在是对人生和生命的极大
浪费。 |
r****s
发帖数: 1025 | 19 另外这个rollback怎么成了高技术了，你们到底用过RHEL的RPM没有？难道没有一个明
白人？
rollback的简单流程：
1. 从proxy/lb那里把tomcat摘下来。
2. rpm erase package,
3. rpm -ih 新package
4. 把tomcat 加到proxy/lb 上。
亚麻的真正高手，在AWS。当然能handle那么多的流量也是不错滴，不过这流量比淘宝
和腾讯差远了，所以虽然也是一流高手，但是绝顶高手在淘宝和腾讯。
小的们有空可以看看淘宝open source的ocean base，还有messaging service。据说每
天handle几十个T的数据（这点我倒是不怀疑）。 |
m******h
发帖数: 1059 | 20 同意你说的，楼主太扯。而且即使a如此之烂 还是写测试的，难道楼主因为先进的工具
连测试都不写？有了sev2就roll back？你觉得那套系统是光速deployment吗？你觉得
所有错都是立即能发现吗？不过话说回来，楼主很适合a的文化，像我们这种做事情有
板有眼踏踏实实的不适应在a乱艹或者被乱艹的 必须赶快卷铺盖滚蛋。
【在 r****s 的大作中提到】
: 我只想草Apollo和Brazil。老子在的时候，build一次要半小时以上，愚蠢到死。
: 我怀疑这帮孙子每次都临时scp dependency package,尼玛local build只要10秒钟，
: submit一个build到完成居然要40分钟。这JB玩意居然商用了。
: 在version set 里resolve conflicts 还是尼玛人工一个一个package地挑出来。
: build 这个过程里99%的工作由javac,也就是Sun搞定了，你也就做一个1%的文件管理的
: 工作量，卧槽还搞得这么复杂。
: 我老人家离开亚麻的一小部分原因，也是这个build system实在是对人生和生命的极大
: 浪费。
|
|
|
c****7
发帖数: 4192 | 21 赞
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
r****s
发帖数: 1025 | 22 我只是觉得一些junior，刚上路，没见过啥世面，一个小trick就大惊小怪的。
Amazon的Dynamo,SRS, EC2之类，这帮人还没摸到边。
Dynamo和Cassandra的关系大家清楚吗？Cassandra算是比较牛逼了,和MongoDB并驾齐驱
。Amazon里面很多东西并不open source。
【在 m******h 的大作中提到】
: 同意你说的，楼主太扯。而且即使a如此之烂 还是写测试的，难道楼主因为先进的工具
: 连测试都不写？有了sev2就roll back？你觉得那套系统是光速deployment吗？你觉得
: 所有错都是立即能发现吗？不过话说回来，楼主很适合a的文化，像我们这种做事情有
: 板有眼踏踏实实的不适应在a乱艹或者被乱艹的 必须赶快卷铺盖滚蛋。
|
z****e
发帖数: 54598 | 23 我看到楼主说热部署就想到了tomcat了
【在 r****s 的大作中提到】
: 另外这个rollback怎么成了高技术了，你们到底用过RHEL的RPM没有？难道没有一个明
: 白人？
: rollback的简单流程：
: 1. 从proxy/lb那里把tomcat摘下来。
: 2. rpm erase package,
: 3. rpm -ih 新package
: 4. 把tomcat 加到proxy/lb 上。
: 亚麻的真正高手，在AWS。当然能handle那么多的流量也是不错滴，不过这流量比淘宝
: 和腾讯差远了，所以虽然也是一流高手，但是绝顶高手在淘宝和腾讯。
: 小的们有空可以看看淘宝open source的ocean base，还有messaging service。据说每
|
h*d
发帖数: 19309 | 24 code rollback了，数据实时更新没那么容易rollback吧，何况UI/MT和DB都需要更新，
特别是schema change时候怎么deploy, rollback?
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
c****e
发帖数: 1453 | 25 所以，现实里面rolleback比deploy还要慎重，hotfix的风险远远小于rollback.schema
change之类的问题非常麻烦，很多时候rollback只能更糟。
【在 h*d 的大作中提到】
: code rollback了，数据实时更新没那么容易rollback吧，何况UI/MT和DB都需要更新，
: 特别是schema change时候怎么deploy, rollback?
:
: version
: 有组
: deploy
: test
|
r****s
发帖数: 1025 | 26 这是两回事，tomcat有hot deployment的选项，如果你的dependency library不是
shared。
这里说的是你得把apache或者load balancer后边拖着的tomcat一个一个轮流取下来，
然后deploy RPM，然后再接回去。这叫live-live，deploy的时候只影响一小部分的用
户。
【在 z****e 的大作中提到】
: 我看到楼主说热部署就想到了tomcat了
|
z****e
发帖数: 54598 | 27 rollback的确不是什么高深的东西
今天出门的路上顺便想了想如何用pure code实现rollback
先把所有要修改的部分上锁
然后备忘录模式做备份
然后执行，如果失败，则丢弃执行后的结果，取备份
如果成功，取执行成功后的结果，丢弃备份
释放资源的锁
这些只要内存足够大，都好办
不过多线程带来的死锁需要去检测
【在 r****s 的大作中提到】
: 另外这个rollback怎么成了高技术了，你们到底用过RHEL的RPM没有？难道没有一个明
: 白人？
: rollback的简单流程：
: 1. 从proxy/lb那里把tomcat摘下来。
: 2. rpm erase package,
: 3. rpm -ih 新package
: 4. 把tomcat 加到proxy/lb 上。
: 亚麻的真正高手，在AWS。当然能handle那么多的流量也是不错滴，不过这流量比淘宝
: 和腾讯差远了，所以虽然也是一流高手，但是绝顶高手在淘宝和腾讯。
: 小的们有空可以看看淘宝open source的ocean base，还有messaging service。据说每
|
z****e
发帖数: 54598 | 28 晓得了，那就是把tomcat本身当成一个app来看
在外层做了一个包装，动态管理这些东东
不过这个东西说起来容易，做起来还是小烦的
因为要涉及到打包什么的，要写代码来做，也算是小冷门一个
【在 r****s 的大作中提到】
: 这是两回事，tomcat有hot deployment的选项，如果你的dependency library不是
: shared。
: 这里说的是你得把apache或者load balancer后边拖着的tomcat一个一个轮流取下来，
: 然后deploy RPM，然后再接回去。这叫live-live，deploy的时候只影响一小部分的用
: 户。
|
r****s
发帖数: 1025 | 29 没看懂，说明你错了。
所有的code都先build to RPM package, 这是RHEL的RPM的规矩。如果你用RHEL,不用
RPM,那就属于自找麻烦。
你的一个build，就是一个RPM，不涉及什么delta.这和SVN/Maven/Git之类的code
management tool没关系。（不过这RPM倒是有点像Git)。
你在系统里先把以前的那个package erase掉，再deploy新的RPM package。就那么简单。
【在 z****e 的大作中提到】
: rollback的确不是什么高深的东西
: 今天出门的路上顺便想了想如何用pure code实现rollback
: 先把所有要修改的部分上锁
: 然后备忘录模式做备份
: 然后执行，如果失败，则丢弃执行后的结果，取备份
: 如果成功，取执行成功后的结果，丢弃备份
: 释放资源的锁
: 这些只要内存足够大，都好办
: 不过多线程带来的死锁需要去检测
|
z****e
发帖数: 54598 | 30 我没有在说rpm和amazon的东西
我只是在想如何用代码实现rollback
模拟的其实是类似db的transaction
跟linux无关
单。
【在 r****s 的大作中提到】
: 没看懂，说明你错了。
: 所有的code都先build to RPM package, 这是RHEL的RPM的规矩。如果你用RHEL,不用
: RPM,那就属于自找麻烦。
: 你的一个build，就是一个RPM，不涉及什么delta.这和SVN/Maven/Git之类的code
: management tool没关系。（不过这RPM倒是有点像Git)。
: 你在系统里先把以前的那个package erase掉，再deploy新的RPM package。就那么简单。
|
|
|
g**e
发帖数: 6127 | 31 hot deployment可以看看OSGI
来，
的用
【在 z****e 的大作中提到】
: 晓得了，那就是把tomcat本身当成一个app来看
: 在外层做了一个包装，动态管理这些东东
: 不过这个东西说起来容易，做起来还是小烦的
: 因为要涉及到打包什么的，要写代码来做，也算是小冷门一个
|
a*o
发帖数: 19981 | 32 卧槽啊，原来纯软件公司都是这么随意瞎闹的，真爽啊，哥得跳过去捣捣乱。 |
s*****m
发帖数: 8094 | 33 灰常的强大，强大到啰里八嗦。呵呵
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
g*****g
发帖数: 34805 | 34 这么做都太容易出错了，最可靠的是NFLX推荐的那一套，直接把所有东西烧进AMI，
部署的时候新的cluster启动了，停掉旧的cluster的，一发现错误一个点击就换回来了。
这么还还有一个极大的好处，auto scaling group，可以动态地根据流量来定cluster
大小。
任何需要手工操作的部署和回退都是危险的。
【在 r****s 的大作中提到】
: 这是两回事，tomcat有hot deployment的选项，如果你的dependency library不是
: shared。
: 这里说的是你得把apache或者load balancer后边拖着的tomcat一个一个轮流取下来，
: 然后deploy RPM，然后再接回去。这叫live-live，deploy的时候只影响一小部分的用
: 户。
|
c****f
发帖数: 1102 | 35 其实 还有个简单的问题
你可以选择rollback 或者为什么不打个补丁 或者修正code以后往上增加一个版本号。
。或者把rollback的版本直接做一个版本号 作为一个新版本发布 这样就不用考虑
rollback以后的平台的同步问题 只要考虑push新版本的同步问题 |
g****r
发帖数: 1589 | 36 非常感谢lz的分享。问个问题啊，aws也是这么搞的吗?如果是的话，aws是怎么pass的
compliance的呢?
version
有组
deploy
test
【在 z*******a 的大作中提到】
: 我老是学文科出身的，所以扯淡从来几天几夜都不累，但是真涉及到CS的具体技术就虚
: 了：毕竟积累太少太差，如果技术有错，大伙轻拍。
: 先说说热门的话题之一：亚马逊的Apollo和Brazil系统，也就是他们的build、version
: control到deploy一条龙。的确很先进，有亚马逊人去了Google甚至认为Google的类似
: 系统也不如亚马逊先进（我个人持保留意见，因为不了解Google）。简单来说强在所有组
: share同一套build-deploy系统，所以只有一个build team一个apollo team什么的管理
: 就行了，什么dependency之类的头疼问题非常好解决，而且deployment可以随时deploy
: 随时rollback，这个真的非常强大。
: 所以亚马逊其实几乎不需要Test。因为（理论上）可以随时deploy，系统一旦出问题立
: 刻rollback，然后再重新改code就是。这就造成了亚马逊很多组就把production当test
|
