大师Grady Booch将软件架构解释为架构是一种设计，但并非所有设计都是架构。架构代表着发展一个系统的重要决定，而这种重要性是通过引入变化的成本来衡量的。

有一本书叫做《恰如其分的软件架构》Just Enough Software Architecture（A Risk-Driven Approach），里面有一种观点，就是对于特定的一个系统，需要做多少相应的架构设计工作呢？如果设计工作容易开展，风险小，也许不需要太多架构投入；如果设计工作风险大，牵一发而动全身，那么就需要加大架构的规划。

引入变化成本将成为架构决策的重要因素，这与我的想法不谋而合，其实架构的演化是与业务息息相关的。所谓业务，从经济学来说，就是利润＝收入－成本，那么架构在演化的时候必须尊重这个基本法则。架构的核心目标是支持业务，增加收入，降低成本，减少费用。

互联网软件的架构大部分都是从三层结构开始的:前端、业务逻辑层、数据库。这可能是大部门业务在初创阶段需要的，为啥这种结构？这是一种解耦，将变化快、中、慢三个层次的模块分为三个部分。前端变化最快，独立起来，中间业务逻辑变化次之，数据层相对稳定。

这样不同速度的变化，可以在自己的赛道上按自己的节奏走。另外一个重要原因是Conway法则，软件的架构总是和组织结构有关，工程师很容易分成前端工程师，服务端工程师和数据库DBA。

那么三层结构是否就无敌了么？在实践工程中，三层结构也不少烦恼，例如通常一个需求会涉及到几个层次的修改，而这种修改需要分散在不同的工程角色中，那么协调的成本很高，排期的过程也要服从木桶原理，最慢的工序将决定最后的发布时间。各个层次的耦合越来越多，越来越繁杂。

举个例子，逻辑层为了加快访问速度，会引入Cache层，这样数据就可能分布在Cache里，或者数据库层。另外，业务层的数据来源可能不全部来源于数据库，很多来源于离线的数据处理脚本，这些数据通常会存放在NoSQL中，例如Redis，HBase等。再进一步发展就是，各个业务使用NoSQL的模式也不一样，有的业务数据量巨大，访问延迟很慢，有的只是配置文件，需要实时更新。随着业务发展，业务层开始使用其他第三方的服务，通过服务接口获取数据。最后，这就慢慢形成了一个网状的服务依赖和数据依赖。

慢慢的，简单的三层结构渐渐堕落成无序的网状结构了。对于网状结构的初期，线上特别容易出问题，容易造成雪崩效应，一个模块的变化容易改变整个系统的服务能力（如果你的架构没有出现过这个问题，也许说明你的业务发展的不够快，不够复杂）。在流量增长迅猛的时候，大家会被迫忙于解决线上问题，架构师也开始谋划架构的长期演化。

很多同学会说，为啥不早早就把架构规划好呢？能够早早把架构规划化，无忧无虑的开发公司估计都破产了，举例来说，有些电商公司在发展初期，对于是做平台还是做服务常常是争论不休的，这样适合的架构也不容易落地的。京东从ASP.NET转向Java，从面向技术的架构转型为面向业务的架构，都是适合业务自发展的需求，从技术角度来看并非是最理想的解决方案。

人们对于过多的层次理解总是有限，一般人对于超过3层的结构，基本就糊里糊涂了，比如说OSI定义了7层结构，但是最流行的确实是TCP/IP的4层结构；J2EE定义的层次复杂性吓的很多创业人，敬而远之，这就是一些轻量级的Spring等框架大行其道；MFC类的继承关系超过3层，开发者基本上就找不到北了，目前还有很多讨论。因此，对于架构的设计，应该服从简单的原则。

按照业务进行系统切分是必须经过的一个过程，分而治之，独立自由发展，这也是业务快速发展初期的必由之路。解耦通常是很痛苦的一个过程。

解耦有很多方式，通常采用以下的一些技术：

• 最通常的是引入队列，通过生产者和消费者模式，减少两个模块的耦合度。

• 通过反转注入IOC，通过配置定义不同的实现。

• 采用事件驱动的设计模式，包括观察者模式，消息链模式等。

解耦之后，整个系统会清爽很多，代码结构会变得很清楚，处女座的同学可以开心一阵子了。解耦可以帮助处理部分的性能问题，特别是异步化的调用。但是，解耦并没有解决各个模块的扩容问题。解耦只是以前缠在一起的问题，解开在不同的独立服务和服务之间的连接中。例如，在通过Kafka队列解耦过程中，队列堆积是经常碰到的问题，如何从监控，控流，容错等方面，改进碰到的问题就是解耦后面首要解决的问题。

在扩容的过程中，会碰到很多瓶颈，这些瓶颈往往是一个接一个的出来，就像打地鼠一样，打死一个，出来一个，打死两个，出来一对。当然，前提是业务的高速发展。

如何处理扩容问题，核心是找到系统的瓶颈，常见的瓶颈包括下面的情况：

● 5.1 数据写瓶颈

• 内存先做聚合，到一定量后统一写入数据；

• 采用NoSQL技术；

• 水平分库和垂直分库。

● 5.2 计算瓶颈

计算瓶颈经常出现在复杂数学模型的计算，随着Features的增多，计算时间变长。计算瓶颈通常需要自定义解决方案，例如内存换时间，分布式计算，分级服务。

例如在搜索引擎中，对于商业性潜力大的查询，可以花费更多的计算。对于长尾词，可以减少计算的层次，以达到节省计算的成本。

● 5.3 存储瓶颈

存储成本几乎是每一个爆发性增长业务都要碰到了，存储包括日志，图片和数据等。存储通常分布在内存，缓存，SSD，磁盘等地方。内存不够用是常见的最大问题，内存通常都被数据塞满了，分布式NoSQL通常是实用的解决方案，如果数据还是大，那么可能需要做索引，可以使用Elastics Search，Lucence等。

 现代软件的架构SOA 

谈到架构，我们都会提到SOA，这是一个老话题，到底什么是面向服务的架构？SOA是通过分布式的服务模块来构建软件系统，服务之间通过接口契约联系起来，而避免了不同模块之间采用不同的方式交换数据，例如文件交换，内存共享，数据库直连等方式。这种方式改善了封装，复用和解耦等方面，适用于复杂的大规模系统。

SOA的第一批实现基本都是企业级别的，例如Java 的ESB(企业服务总线），实现过于笨重，部署过于复杂。与此同时，各个互联网企业也基于SOA进行大量开发工作，也积累了很多SOA，特别是分布式的经验。

为了加快SOA的开发节奏，充分利用云部署的架构进行水平扩展，一种轻量级的SOA方法正在慢慢的流行起来,这就是微服务。

微服务是组织和利用分布式能力的一种模式，微服务提供一个高性能的服务接口，是进程之上的一种模式。提供独立的业务能力,特别强调的是，独立的业务能力；微服务是用一组服务来构建应用，服务独立部署在不同进程中，不同服务通过轻量级的交互来通信，例如RPC，HTTP，服务可独立扩展和伸缩，每个服务定义了明确的边界，独立团队来维护。

微服务特征包括以下8个方面：

• 组件化；

• 业务组织团队；

• 服务就是产品；

• 去中心化；

• 基础设施自动化；

• 容错设计；

• 计划设计；

• 服务质量保证。

虽然对于软件架构的技术有很多研究、发展、创新，但对于架构师这个角色却缺少经验，例如对于公司是否需要专职架构师有多种不同意见。很多公司的架构师实际上是开发经理或者研发总监担当，因为架构师直接带领团队，因此架构演化执行的效率高。

但是也有很多公司（例如微软）的架构师是一个IC角色，换句话说他们需要靠自己的影响力推动架构演化和升级，而开发经理更加直接面对业务需求，这个时候短期业务开发和架构长期演化需要在不同的角色中达到平衡。

这种不同实践的核心问题是“对定一个系统，需要多少专门的架构设计工作？”一个关键问题是，如果一个项目没有太多的设计风险，说明架构在一个好的状态，不需要太多的架构工作；如果一个系统的设计风险很大，每一个业务实现都需要过多的考虑设计风险，那么说明这个项目的架构需要大力投入了。这就是风险驱动的架构设计。

架构师在面对复杂问题时，像很多人一样，首先收集足够多的数据，将问题描述清楚，抽象来说，架构师处理复杂问题的三种基本方法：分解（分而治之）、抽象（大象无形）、知识库（见多识广）。

• 分解通常是按照一定的角度对系统进行拆分，角度通常是按照业务、功能和团队等方式来做。举例来说，如果是国内和国外的合作项目，尽量会选择没有减少依赖的方式来拆分和项目管理。分解之后的联系通常使用简单、可靠的接口来定义，包括SLA等。

  
  

• 抽象是屏蔽了细节的一种方式，就像大象无形，很多人真正把架构问题想透以后，抽象到最简单和基本的问题，就容易推动架构的演化。举一个例子，飞机是非常复杂的，但是如果将飞机制造抽象成物理部件系统、空调系统、机电系统、光电系统，等等，那么理解起来的难度就会降低很多。

  
  

• 利用知识库也是架构师重要的技能，利用互联网快速找到相关的信息，多学习学习别人走过的路，踩过的坑。早年的软件工程所强调的领域工程，也是希望通过工程化的方式，把已经有的行业知识积累起来，为他人所用。