论系统设计之纵横之术

    细数，踏入it职场，已有2载，一直从事某互联网公司非用户端后台系统业务的开发。虽然面对的业务范畴，没有超强的并发流量冲击，也没有较高的系统性能要求。但是其所面临的业务逻辑之复杂性，让我有了写这篇文章的底气。

     说到这里，也不得不说扯起一个话题，系统的高性能与业务的复杂性往往是一个对立。一个系统，如果想要面对超高的流量冲击，超强的系统响应，那么它所承载的业务逻辑的复杂性也必然要降低。我们在优化一个系统的性能，其本质也就是在不断的拆分、裁剪一个复杂的业务逻辑线。一个业务逻辑，决定了几次db的访问，几次rpc的调用，最终也就直接决定了系统的rtt。对一个富有经验的开发来说，总会在业务逻辑的制约下，通过各种技术手段，用跟更高效的cache冗余存储，用更多的计算资源并发压榨，等等通过各类空间资源的消耗来换取时间，以其达到系统性能优化之目的。这也是我们优化系统的一个基本思路。诚然，在90%的情况下，我们这么去做，都会有一个很好的效果。但是，我们往往忽略另外一个问题，就是这么做的前期是我们受业务逻辑的制约。换句话说，我们的系统的业务逻辑，已经到了没有办法优化的地步，我们对其每一步的妄加修改，都将导致这个流程土崩瓦解，发生crash。往往，由于我们面对的是一群头脑发热天马行空的产品，他们交付给我们的流程设计，往往很难碰触到这样的场景。或者刚开始是这样的场景，可是随着业务的发展，树木的成长，边边角角的枝干成长，逐渐淹没了主干，让我们看不到我们曾经的核心逻辑。最终，迫使我们不断的通过各类技术手段去优化，有一定的事半功倍。

      因此，本文想不以一行代码，来探讨一个系统之设计。使用的方法就是纵横之术。

      纵横，乃鬼谷立派之本。作为秦迷，看到纵横，无不肃然起义。言归正传，这里纵横之术，纵，即乃一个业务逻辑的核心逻辑；横，即乃一个每一个步骤中的各类充要条件。举例来说，一个系统，更细一点，一个电商系统。其简单概括由基础数据和各种各样的事情组成，放到大千世界，则上升为万物是由万物自身和万物与万物之间的关系组成。这里，我们探讨电商系统中的各个各样的事情；基础数据，准确的说，对基础数据的管理，这里不予展开。电商系统中的各类事情，比如用户的下单流程、商品的入库流程、商品的发货流程。每一个流程，我们可以分为好几步，比如几个点，少了其中的某一步，那么这个流程就会产生crash。这样的一条线下来，就是所谓的纵。比如，下单流程中的几步： 当事人提交订单、锁库存、去支付、成功orfail；商品入库流程，提交入库单据、推送到仓库、仓库理货、仓库回传理货单据、审核单据、入库上架；等等，这样的一条线。而在这条线中的每一步，每一个点，我们可以逐渐的去展开，去进行我们的横向拓展，业务上玩各种各样的花样，技术上玩各种各样的实现方式。

      这样，一但我们的纵定下来，我们系统的rtt基本定下来。一方面我们在我们定下来的纵上，通过技术手段不断的进行优化改造，使其rtt更高。另一方便，无论产品怎么在横上做文章，只要不要动纵上的某一个牟钉，那么我们的rtt就会保持。另外一定要注意的时，在我们的横向逻辑实现时，一定要始终牢记尽可能的减少和避免对我们的纵向逻辑产生影响。这样，我们设计的系统，不论何时何地，都会牢牢的掌握在我们的心中，哪怕横的错综复杂，只要我们的纵不丢，我们系统就稳定可靠高性能。

     这就是本文想表达的，惭愧，好久不动笔。逻辑有点乱，此文仅记录点滴思考。