程序员探险记6-架构篇-望远镜

 

规模复杂庞大的系统需要有人站在更高的视角上去关注整体性的东西，像望远镜那样看得更远，掌控全局。

究竟什么是架构，可能每个人的理解和关注点不尽相同。这里不得不提一下康威定律，值得每个架构设计者认真思考一番。定律的原文为：“Any organization that design a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.”。我理解架构的本质是平衡系统熵增的过程。 公司发展过程中需要不断调整组织架构来解决沟通效率问题；软件系统架构也要在业务扩张中解决系统熵增的问题。所以我们经常听说 好的架构不是设计出来的，而是跟随业务演进而来的。说明它是一个持续的过程，而非一个结果。特别是持续交付，敏捷，devops等的普及，你一开始精心设计的架构，可能在几个月的迭代后已经大变样。这块将在下一篇【工程篇】中再展开讨论。

理解了本质，再来看看架构的目标是什么。对于软件系统架构，其设计直接影响着系统的生产，比如开发过程和效率、代码和组件复用性等，同时也影响着系统的可用性、伸缩性、性能、扩展性和安全性。这些目标往往是相互影响的，比如为了追求安全性会牺牲小部分性能，追求扩展性而牺牲了性能的冯·诺伊曼瓶颈。所以架构往往需要一定的折中，根据业务情况在各个目标之间寻求一个动态的平衡（从组织架构看，其实也是在平衡各方的利益）。

而为了达成架构的目标，你需要什么样的能力呢？在前面章节中多次提到的结构化思维能力，就是最基础的架构能力。结构化就是将逻辑进行抽象、提炼、分解、聚合，构建成更加缜密、动态、弹性、边界清晰的结构体。其次是平衡思维(也有人称之为灰度思维，的确这个世界很多事情不是非黑即白的)能力。记住没有完美的架构，只有合适的架构。要根据业务目标作出自己的判断，有所取舍，并通过良好的沟通能力确保各方对架构达成共识，在现有资源约束下最合理。

关于软件架构设计，是有一些原则的，核心就是高内聚和低耦合。具体包含的SOLID原则在上一篇【编程篇】中有说明。这里，我总结了一个自己的理解，就是一个中心【以用户为中心】，两个基本点【拆分与治理】。其中拆分包含横向的分层(Slice)和纵向的分块(Dice)。

分层在系统架构中大量存在，比如：

    网络分层，不管是OSI网络模型还是TCP/IP都是分层的设计；

    操作系统，介于计算机硬件和应用软件之间的一个软件层；

    JVM虚拟机，屏蔽了与底层具体平台信息相关的抽象层；

    缓存，是在应用与数据源之间的一道缓冲层；

    消息队列，是在生产者和消费者之间的一个解耦层；

    控制反转（IOC），是在两个组件之间的一个中介层；

    容器，是一个层层重叠的集装箱；

    适配器模式，桥接模式，代理模式都需要一个独立的层；

    ......

分块同样存在不少，比如：

    数据库分库分表（数据分片）；

    冗余备份技术；

    负载均衡集群；

    微服务模块拆分；

    MapReduce；

    敏捷开发模式（小团队与迭代）;

    ......

治理是要解决系统拆分带来的相应问题如稳定性、一致性等（因为天下没有免费的午餐）。那么如何衡量你的拆分效果呢？彼得·德鲁克说过，如果一个事情，你不能衡量它的话，那么你就不能改进它。精益文化里三点——Build（建立）、Measure（衡量）、Improve（改进）也体现了衡量的重要性。

治理的核心原则就是要达到统一共识，从整体上对系统运行情况进行控制。尤其是分布式架构中，如果不能达成共识，将发生数据不一致，脑裂等各种问题。系统在拆分的过程中，是不能离开治理者的视线的，你必须始终站在全局的角度整体考虑这样的拆分是否合理。在已经拆分的系统中，不能因为一个点的错误，引发系统级的崩溃，所以限流降级、熔断机制等常用治理手段是一个系统完整统一的保证。同时你还会发现这些手段跟生活是分不开的，比如熔断就是一个保险丝，股市的一种风险控制措施。再次说明了【学习篇】提到的计算机世界是模拟的人类世界。

有了技术架构的支撑，怎样快速响应业务的发展需求呢？接下来请看下一篇【工程篇】。

 

回到首页——程序员探险记1-开篇-起航