5分钟经过水痘事件来认识系统架构

这是我参与8月更文挑战的第4天，活动详情查看：8月更文挑战

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

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

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

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

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

水痘是什么？

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

我小时候确定是打过疫苗的，可是没想到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系列

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