天下武功，唯”拆“不破之架构篇一 | 技术人应知的创新思维模型 (7)

前篇系列文章我们聊了聊什么是组合创新？如何落地组合创新？如何进行既有要素的拆解？ 读者可能会问，这些与技术打工人的拿手绝活（技术）又何种关系？ 今天笔者就与大家简单聊下组合创新中的拆解在架构设计中的应用。



场景： 医药交易系统上线深受市场青睐，业务发展迅速，高峰期，早期的单体应用核心业务流程交易订单下单接口请求由每秒TPS由200次/秒，迅速发展到2000次/秒；老板看到商城系统订单量、GMV、客单价都在持续增长十分喜悦，但随着业务的快速增长，一系列的技术底层问题也开始显露，系统宕机越来越频繁、告警不停，客户投诉增多，于是老板找技术老大“喝茶”。技术老大压力倍增，架构同学必然是如坐针毡、焦头烂额。

面对这种场景我们该如何破解？ 如果是你作为架构负责人，你会从何做起，如何高效应对？不妨带着问题继续一起细读后文。

一、架构拆解的角度与尺度

天下武功，唯“拆”不破，依然“拆”字诀应对，我们先回顾下前文提及的拆解方法：

组合创新中即有要素拆解常见方法有两种，一种方法为尺度，另一种方法为角度；

尺度上简而言之就是拆得越细小，越能发现问题的关键要素，发现事物的本质；

角度上简而言之，就如乔爷所言“Think different””See things differently“；选择不同的角度，可以让你看到不一样的问题点，抓着不一样的机会点，让你从红海中找到蓝海。

• 普遍场景下，架构设计是优先选择角度，还是尺度进行分解？

基于架构设计服务业务、驱动业务的初衷，一般场景下设计因优先从业务角度出发，如站在业务发展的角度、站在收入的角度、站在架构设计ROI角度等，而不是站在炫技的角度、尝鲜的角度、局限性的纯技术角度；其次从尺度出发，如服务拆分尺度、数据分拆分尺度、可用性尺度等，尺度上尤其需关注“灰度”、“折中原则”，服务拆分上，大可不必将一个低并发、相对稳定的版本大拆八块，美其名曰，前瞻性驱动业务；可用性尺度上，也不必追求非核心业务4个9以上的高可用；对于创业公司，初期业务尚没有成长起来，企业发展上并未突破破局点，此时架构设计过度前瞻、性能上过度设计、服务上过度拆分，只会加速创业初期的资源耗尽与拖累业务的迭代速度，其他则毫无意义。

只考虑角度，不考虑尺度，难以着手解决具体问题，可能会带来较低的ROI，只考虑尺度不考虑角度也往往会设计或优化错方向。



• 回到文中开头的场景，为了让线上系统快速恢复到理想状态，我们从以下两个维度拆解分析：

第一角度：针对订单并发激增问题，选择的角度应该是站在客户的角度、收入的角度而不是客服的角度、纯技术的角度，即优先保证核心业务高可用：保证商品浏览、交易支付的全流程稳定性和流畅性，避免订单流失。

第二尺度，针对文中线上问题最重要的尺度是从可用性与时间尺度着手考虑，为了尽快恢复线上系统的平稳运行、避免系统崩溃，时间尺度上要求我们必须最短时间内提升系统性能，那么无疑应避免优先考虑难以在短时间（24小时内）实施的方案，如服务垂直拆分、系统水平分层、核心业务与非核心业务分离、公共服务下沉、非核心业务调用异步化、数据异构、引入分布式中间件消息队列、缓存等等方案，而是应遵循采用最小改动、最小作用量原则从如下两个方向进行应对：

1. 纵向：通过优化核心业务接口单次调用性能提升TPS，常见策略硬件方面如数据库存储由机械硬盘转向SSD磁盘、扩展CPU、增加服务器内存等、软件方面如分析数据库sql执行计划优化高频SQL、数据库读写分离、Web容器参数优化、JVM参数优化、增加本地缓存等等

2. 横向：通过硬件快速扩容，横向扩展扩容提升TPS，常见策略添加多个应用服务器通过接入层nginx网关做负载均衡，将流量分发到多个应用服务器中的web应用服务。

二、架构拆解的时机

• 架构演进是不断反熵增与提升需求响应力的发展过程

可能有人会问：为什么如此定义，底层逻辑是什么？

一方面随着时间的推移，伴随着业务不断发展；组织规模不断变大、内外部需求不断变多、需求迭代频次越来越快，架构设计上需要应对的业务场景与线上问题只会越来越多、因此必然需要不断演进架构去提升需求响应的能力，才能让业务系统迭代的速度与公司业务发展相匹配。

另一方面熵增定律表明，在自然过程中，一个孤立（封闭）系统的总混乱度（即“熵”）不会减小；只会随着时间推移不断的混乱无序，最终走向消亡；此刻，你不妨回想下自己所在公司的系统与架构是否不断经历从无序到有序再到无序不断反复的过程；所以也同样需要架构的演进去不断的让系统由无序到有序，即反熵增的过程。





• 架构不断演进的背后即是不断的拆解，而拆解时机价值千金

架构服务业务，业务驱动架构，脱离业务场景去谈架构必然是不合格的架构师所为；因此为了打造最契合业务发展阶段的架构，需要架构同学选择合适的架构拆解时机。





比如对于公司业务发展初期、破局点之前的商业模式探索阶段，往往意味着资源相对有限、业务场景相对简单、产品功能简洁、研发人员少、并发量也基本不大；所以此时不论是基于成本考虑还是公司业务考虑，无疑需要的是保守的拆分策略而不是激进的微服务化拆分；创业维艰九死一生，作为架构同学尤其不能在业务还没有10X（10倍数）变化、走出破局点前就让架构设计10X变化迭代，早期架构的过度设计 90% 以上的概率只会是创业初期的无用设计与有限创业资源的无畏浪费；因此架构最好的拆解时机是稍晚于企业业务发展的破局点。



架构师进行架构设计拆分前，业务处于S曲线上的哪个位置，业务的发展是否已过破局点、业务的发展是否已经接近极限点是架构师必须明确的业务发展状态。