fenixsoft
「Comment」https://icyfenix.cn/introduction/about-the-fenix-project.html
请设想一下，如果你的系统中每个部件都符合“Phoenix”的特性，哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃。而即便这样，只要在整体架构设计有恰当的、自动化的错误熔断、服务淘汰和重建的机制，在系统外部来观察，整体上仍然有可能表现出稳定和健壮的服务能力。 这个观点我不太认同，如果代码真的垃圾到单实例只能支撑10来个并发就崩溃，那么即使服务可以自动重启、扩容、熔断也没什么意义，除非拥有无限的计算资源。 比如：
- 1.实例一个接一个崩，系统的负载能力就越来越低。
- 2.内存用得越快，GC频率越高，CPU时间都花在GC上。
- 3.动态扩容需要时间，即使是10多个秒就可以自动新增一个实例。但是自动扩容的速度还跟不上宕机的速度。
- 4.熔断，不断地熔断。
@zhong2312 请设想一下，如果你的系统中每个部件都符合“Phoenix”的特性，哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃。而即便这样，只要在整体架构设计有恰当的、自动化的错误熔断、服务淘汰和重建的机制，在系统外部来观察，整体上仍然有可能表现出稳定和健壮的服务能力。 这个观点我不太认同，如果代码真的垃圾到单实例只能支撑10来个并发就崩溃，那么即使服务可以自动重启、扩容、熔断也没什么意义，除非拥有无限的计算资源。 比如：
- 1.实例一个接一个崩，系统的负载能力就越来越低。
- 2.内存用得越快，GC频率越高，CPU时间都花在GC上。
- 3.动态扩容需要时间，即使是10多个秒就可以自动新增一个实例。但是自动扩容的速度还跟不上宕机的速度。
- 4.熔断，不断地熔断。
额。。。能不能不要没有意义地杠。作者这里强调架构层面的局部可再生性，进而维持整机架构的自我修复和适应能力
@zhong2312 请设想一下，如果你的系统中每个部件都符合“Phoenix”的特性，哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃。而即便这样，只要在整体架构设计有恰当的、自动化的错误熔断、服务淘汰和重建的机制，在系统外部来观察，整体上仍然有可能表现出稳定和健壮的服务能力。 这个观点我不太认同，如果代码真的垃圾到单实例只能支撑10来个并发就崩溃，那么即使服务可以自动重启、扩容、熔断也没什么意义，除非拥有无限的计算资源。 比如：
- 1.实例一个接一个崩，系统的负载能力就越来越低。
- 2.内存用得越快，GC频率越高，CPU时间都花在GC上。
- 3.动态扩容需要时间，即使是10多个秒就可以自动新增一个实例。但是自动扩容的速度还跟不上宕机的速度。
- 4.熔断，不断地熔断。
额。。。能不能不要没有意义地杠。作者这里强调架构层面的局部可再生性，进而维持整机架构的自我修复和适应能力
你得先理解我的意思，还有你要有相当程度的实践再来和我抬杠，你只是从教科书层面去理解作者的思想，而我是从实践层面去否定作者的思想。“哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃” 我表达的核心思想是，如果出现这种情况，任何架构都抗不住。
@zhong2312
@zhong2312 请设想一下，如果你的系统中每个部件都符合“Phoenix”的特性，哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃。而即便这样，只要在整体架构设计有恰当的、自动化的错误熔断、服务淘汰和重建的机制，在系统外部来观察，整体上仍然有可能表现出稳定和健壮的服务能力。 这个观点我不太认同，如果代码真的垃圾到单实例只能支撑10来个并发就崩溃，那么即使服务可以自动重启、扩容、熔断也没什么意义，除非拥有无限的计算资源。 比如：
- 1.实例一个接一个崩，系统的负载能力就越来越低。
- 2.内存用得越快，GC频率越高，CPU时间都花在GC上。
- 3.动态扩容需要时间，即使是10多个秒就可以自动新增一个实例。但是自动扩容的速度还跟不上宕机的速度。
- 4.熔断，不断地熔断。
额。。。能不能不要没有意义地杠。作者这里强调架构层面的局部可再生性，进而维持整机架构的自我修复和适应能力
你得先理解我的意思，还有你要有相当程度的实践再来和我抬杠，你只是从教科书层面去理解作者的思想，而我是从实践层面去否定作者的思想。“哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃” 我表达的核心思想是，如果出现这种情况，任何架构都抗不住。
你否定作者的思想前，需要先理解作者的思想，作者的意思是从整体的软件系统来看，当系统中某个原子服务出现了灾难性的问题，如果整体的架构设计合理，影响的也只是问题服务的可用性，不会出现雪崩效应，导致整个系统变得不可用。 凤凰架构，我理解就是要保障系统从整体上来看是健壮的，有韧性的，禁得起反复蹂躏的，一个部件（原子服务）即使死了也不会影响其他部件，甚至该部件能自我恢复，这就是系统韧性的体现。分布式系统中，错误是避免不了的，就像人的细胞总是会死亡，重生，但是人作为一个整体一个系统他是健康的。
@zhong2312
@zhong2312 请设想一下，如果你的系统中每个部件都符合“Phoenix”的特性，哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃。而即便这样，只要在整体架构设计有恰当的、自动化的错误熔断、服务淘汰和重建的机制，在系统外部来观察，整体上仍然有可能表现出稳定和健壮的服务能力。 这个观点我不太认同，如果代码真的垃圾到单实例只能支撑10来个并发就崩溃，那么即使服务可以自动重启、扩容、熔断也没什么意义，除非拥有无限的计算资源。 比如：
- 1.实例一个接一个崩，系统的负载能力就越来越低。
- 2.内存用得越快，GC频率越高，CPU时间都花在GC上。
- 3.动态扩容需要时间，即使是10多个秒就可以自动新增一个实例。但是自动扩容的速度还跟不上宕机的速度。
- 4.熔断，不断地熔断。
额。。。能不能不要没有意义地杠。作者这里强调架构层面的局部可再生性，进而维持整机架构的自我修复和适应能力
你得先理解我的意思，还有你要有相当程度的实践再来和我抬杠，你只是从教科书层面去理解作者的思想，而我是从实践层面去否定作者的思想。“哪怕其中某些部件采用了由极不靠谱的人员所开发的极不靠谱程序代码，哪怕存有严重的内存泄漏问题，最多只能服务三分钟就一定会崩溃” 我表达的核心思想是，如果出现这种情况，任何架构都抗不住。
哈哈，作者这段话显然是要表达某种东西，而不是字面意思！比如有人说，“是真男人就不要打女人”，只是想强调某种男女相处之道。你倒好，举一堆例子说明在哪些场景下男人是可以打女人的。
