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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这不是老早就已经是业界标准了吗? : : version : 有组 : deploy : test
|
h***i 发帖数: 1970 | 7 这个图有年头了
【在 d********g 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这不是老早就已经是业界标准了吗? : : version : 有组 : deploy : test
|
c******a 发帖数: 789 | 8 太牛b了
如G
赞!记下了!
这么不scalable?
【在 h*****a 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 太牛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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 真不懂这个CI/CD有什么好说事儿的。大部分end user facing 的公司都有这个。 : : version : 有组 : deploy : test
|
l******g 发帖数: 366 | 14 ci/cd的idea都很简单,但人多了以后还能保持高效是非常非常难的。
【在 l*****t 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 真不懂这个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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : lz哪个组啊?deploy之前不test?不是tier-1 service吧。。
|
p**********e 发帖数: 316 | 17 A能做到100% SOA, 这样模块之间, 不同部门之间的coupling就减少很多,这个系统相
对来说更容易实现.
如G
【在 h*****a 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我只想草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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 同意你说的,楼主太扯。而且即使a如此之烂 还是写测试的,难道楼主因为先进的工具 : 连测试都不写?有了sev2就roll back?你觉得那套系统是光速deployment吗?你觉得 : 所有错都是立即能发现吗?不过话说回来,楼主很适合a的文化,像我们这种做事情有 : 板有眼踏踏实实的不适应在a乱艹或者被乱艹的 必须赶快卷铺盖滚蛋。
|
z****e 发帖数: 54598 | 23 我看到楼主说热部署就想到了tomcat了
【在 r****s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 另外这个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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我看到楼主说热部署就想到了tomcat了
|
z****e 发帖数: 54598 | 27 rollback的确不是什么高深的东西
今天出门的路上顺便想了想如何用pure code实现rollback
先把所有要修改的部分上锁
然后备忘录模式做备份
然后执行,如果失败,则丢弃执行后的结果,取备份
如果成功,取执行成功后的结果,丢弃备份
释放资源的锁
这些只要内存足够大,都好办
不过多线程带来的死锁需要去检测
【在 r****s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 另外这个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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这是两回事,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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : rollback的确不是什么高深的东西 : 今天出门的路上顺便想了想如何用pure code实现rollback : 先把所有要修改的部分上锁 : 然后备忘录模式做备份 : 然后执行,如果失败,则丢弃执行后的结果,取备份 : 如果成功,取执行成功后的结果,丢弃备份 : 释放资源的锁 : 这些只要内存足够大,都好办 : 不过多线程带来的死锁需要去检测
|
z****e 发帖数: 54598 | 30 我没有在说rpm和amazon的东西
我只是在想如何用代码实现rollback
模拟的其实是类似db的transaction
跟linux无关
单。
【在 r****s 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 没看懂,说明你错了。 : 所有的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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 晓得了,那就是把tomcat本身当成一个app来看 : 在外层做了一个包装,动态管理这些东东 : 不过这个东西说起来容易,做起来还是小烦的 : 因为要涉及到打包什么的,要写代码来做,也算是小冷门一个
|
a*o 发帖数: 19981 | 32 卧槽啊,原来纯软件公司都是这么随意瞎闹的,真爽啊,哥得跳过去捣捣乱。 |
s*****m 发帖数: 8094 | 33 灰常的强大,强大到啰里八嗦。呵呵
version
有组
deploy
test
【在 z*******a 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 这是两回事,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 的大作中提到】![](/moin_static193/solenoid/img/up.png) : 我老是学文科出身的,所以扯淡从来几天几夜都不累,但是真涉及到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
|