规划驱动架构和故障驱动架构

前言

在我看来架构驱动一般分为两种，规划驱动的和故障驱动。

前者更能体现出架构师在业务角度和技术角度的前瞻性能力，后者可能是出如今业务高速发展阶段，大部分时间只能疲于应付吧。

好比在双十一咱们常常听到由于流量过大形成服务瘫痪，系统不可用。

虽然咱们经过创建可靠的上线，测试，部署流程。指望在测试及灰度阶段发现性能和可用性的潜在问题，但大部分仍是难以免线上的故障。

架构想要什么

架构的关键词：高可用，高并发，大数据，分布式，自动化。

故障驱动的架构师老是但愿经过系统升级迭代，搞定那些线上暴露出的问题，修复他，对于那些还未发生，认为是不存在的。

固然大部分架构的发展是来自于业务需求，那咱们是否还须要主动驱动架构？

架构很差预估，通常在大流量下咱们才能更好的观察咱们的系统能力。

“系统自动扩缩容”，“在流量不一样时进行自动调整”听上去很赞，可是每每在黑天鹅来了以后仍是哑火了，好比微博接入混合云后，号称自动扩缩容同时支持八对明星并发出轨，而后在鹿晗找了女友后就挂了。

规划系统

因此咱们要明确的目标和将实施方案写进规划，讨论，落地，执行，折腾。

每次在分布式中间件，持续集成持续交付，DevOPS等折腾后，和行业内伙伴学习交流，关注发展历程和技术选型，将这些计入标准细节。每次都会有收获有启发。

创建破坏性故障演练，制定模拟场景，好比拔网线，丢包，IO不规则波动，消息堵塞等，去不断演练，坚固系统。