事情是这样的，最近学委居然被水痘病毒拿下了。。。

哎，之前生活作息没把握好节奏，写文章后太兴奋了有时候睡不着，休息不足免疫力就下降，只能说写文章是一把双刃剑。（也奉劝各位读者朋友们注意休息，身体健康最重要！）

好，暂时放下这把剑，去看医生。被告知这是常见病毒，只是偶尔有些人免疫力下降没抵抗住，就会被感染。

不是说系统架构吗？？？先看下图，请带着这个问题继续看吧。

（学委就是里面那个冒红的块，其他都是正常健康的同事们）

水痘是什么？

水痘是一種急性高度傳染性疾病，症状就是会发痒发红，通常得过一次就一般不会再感染。（学委不是水痘专家，这里只是简单摘述）

我小时候肯定是打过疫苗的，但是没想到N年后居然被再次攻击了！

得了水痘之后周围发生了什么？下面是整个事件。

1. 周五发现腰部有点痒，长了一小块痱子（只觉得是小问题），恰巧约了朋友周一吃饭。
2. 下周一，还没有好挂了号。我跟两个朋友吃饭，检查完马上告诉他们（告诉哥们要酒精消一下毒）
3. 那天差不多下班单位立马安排了消毒，让周围的同事一周内在家上班。
4. 也让学委在家多注意休息，不过问题不大暂时没有休假，继续在家里上班了。
5. 部门上报并通报了这个事件，呼吁大家注重休息和生活卫生。

那么，这关系统什么事？？？

公司其实就像一个系统，部门就像一个服务群，而学委就是里面的一个微服务。当然这个平台也有几个类似学委这样的微服务（就像下图一样，蓝色框内为一个公司，里面很多打工人，箭头为服务间交互）。

上图，除了学委这个服务变红了，其他服务还是绿色的，正常运转的状态。（请再看一眼这个图，后文会继续讲学委跟几个同事交互之后的变化）

遇到问题，让系统尽量不崩溃，保持正常或者近乎正常的运行，是每个架构师必须做好的事情。

这里，有必要了解系统思维

所谓系统思维（System Thinking），就是把某个疑问、某种状况或某个难题明确地视为一个系统，也即是视为一组相互关联的实体，而不是孤立的一个对象。

在公司，每个职能部门，处理应对业务，应对一个一个问题。这就像及了应对一个问题的整体架构！

系统思维的初级目标是理解系统是什么，更进一层的目标是为了预测系统在发生某些变化之后的情况。而最高级的目标，则是用部件来合成一个系统，这个过程就是系统架构。

每个员工个体就是部门里面的一个个服务，当然职能还有前端，后端，业务分析人员，架构师，和其他管理等等，这些相当于不同类型的实例。

这些公共协作对外为处理系列问题的一个系统！

针对这个bug（水痘）的处理？

系统级别的处理

类似的，我们可以看到在公司做了上面的一些措施，遏制病毒的进一步扩散，避免感染影响更多的微服务。

同时把问题上报，公布问题，带来更高级别的关注和避免了更多可能的服务交互。

这些行为就像微服务里面进行业务隔离（下图的虚线和实线包起来进行不同级别的隔离），警告展示在大面板（群发公告这个事件），实现中央化统筹一个样啊。

服务级别的处理

就像雷学委微服务一样，一开始以为长痱子，没多想跟其他服务交互（比如更哥们吃吃饭，回去公司跟小伙伴交流技术）。

但是，服务内部有设置状态监控，学委生病一开始以为是腰上长了一点点痱子，没理会，第四天发现还没有好。

看病前4天已经约了朋友吃饭，也不知道是啥，所以就去吃饭了。但也没有犹豫下午就请假去看医生了。

然后跟确认病情后，通知部门，然后公司安排系列后续处理。

我则在家上班，也避免影响其他人。

这是一种服务的组件自治的体现，自我管理，自我故障处理，不行再向上汇报。

如果以上措施都没有呢？

那么就像下图一样，红色为被传播水痘病毒的同事，在系统中体现为多个服务无法正常运转导致整个系统在外部看来是崩溃的。

也就是我们常说的挂机了，类似之前B站崩了。

有些读者跟着文章读，很容易被带入了，觉不是很自然吗？

那么，你可以想想下面的问题？

要是没有去看医生呢；

要是看医生后忘记及时告诉公司了呢；

要是告诉同事，他们没有理会约束呢；

要是告诉部门没有任何举动等等。

虽然水痘也不是那么吓人，但遇到抵抗力低的照样传播开来，那就影响更多部门，甚至更多系统（公司与公司之间业务交互的影响）。所以，若没有上述处理，这个事情可能影响更大。

类似问题可再想想，重新审视一下你所接触过的系统或者项目。

比如某一次提交代码，小八（他是新加入项目的）就写了一个for循环，本地测试好好的。
放到线上后运行了一段时间后导致一个查单服务Java进程发生OOM。
结果调用服务不断重试，自然地把其他查单服务压垮了，最后所有调用方不断重试，还把网关压垮，全员紧急加班查问题。

那么有没有什么架构方案是像万金油一样，一劳永逸的呢？

答案是没有。生活还是有其他万一的，我们无法都考虑进来。很多技术人员会听到6个9，也就是一年挂机不超过31秒，很难达到吧。

 (1-99.9999%)*365*24*60*60=31.5秒(向下取整数）

只能说架构应该具有相对的适用性，超前性（N倍性能的弹性设计，但不可能是百倍性能的规划），演化性（平台不是第一天就成为平台）。这不就跟公司成长一样嘛。

总结与延伸

类似水痘这个bug是无法避免的，因为消除不了，但不属于那种致命问题，有时候也不会被重视。

做系统也一样不能说完全没有Bug，只是多数情况下还不是主要矛盾，可以忍受（再没有遇到那个情况触发下）。

怎样的架构能过避免出现大规模故障呢？

• 打造高质量服务
  自我感知，告警，熔断，健壮性等等。这对应于员工则是招聘培训高素质员工

• 必备风险管理方案

流量销峰，加缓冲队列，业务隔离，服务隔离，多个服务实例，还有支持伸缩。这对应于公司则是针对故障的一系列高效处理流程：比如合理业务线划分，分布式团队带来错峰弹性，和支持移动办公等等。

当然更加弹性更加可用，那么系统的成本就越高了。对应的就是企业增加了管理成本，高素质员工带来的支付更高的薪酬。

最后，年轻人如何了解并学习架构呢？

对新手来说，看书估计是很难的，你没有到那些问题，看到一些文字估计停留在浅尝辄止！

学委觉得最好的方式就是，观察，模仿，找到团队里最厉害的人（可以是架构师，可以是最牛的那个技术）。

多跟他交流，思考为什么，他也不一定都对（除了技术，还有工期，团队能力，预算等外界因素）。这个思考的过程，再去看资料，才是更加实战的学习架构经验之道！

好了，旨在引发思考。这次水痘经历，让我们看到这个一连串的事情和一系列处理。灵机一动，学委用来类比了系统和微服务的监控，运维，架构设计，也没有全面涵盖！

另外更加感兴趣的朋友，可自行去看《系统架构：复杂系统的产品设计与开发》，超级经典的一本，更多还是实战。

对了，学委还有这个可以关注长期阅读 =>雷学委趣味编程故事汇编
或者=> 雷学委NodeJS系列

持续学习持续开发，我是雷学委！
编程很有趣，关键是把技术搞透彻讲明白。
创作不易，请多多支持，点赞收藏支持学委吧！