前言：

架构是达成商业目标的一种解决方案，达成商业目标可以有多种解决方案，也就可以有多种架构，但是什么样才是实现这个商业目标最理想的架构呢？

什么是架构：

什么是架构，从不同的用户角度看会得到不同的答案。

1、从客户的角度来看：什么架构都无所谓，只要能提供给我“好快省”的系统用就可以。

2、从产品开发人员的角度看：架构让系统容易理解、修改、替换以及有统一的语言，能够让开发人员都遵循统一的约定、规则和约束。

3、从产品运维人员的角度看：架构让系统容易部署、扩展、监控以及能快速从失败中恢复，能够有效地降低运维成本。

4、从项目经理的角度看：架构让系统开发效率和质量高，能够保证版本按时按质发布。

5、从测试人员的角度看：架构让系统容易测试，能够保证新增的功能不会影响已有的功能，修改某一个功能不会影响和它无关的功能。

不同的用户有不同的关注点，不同的用户关注架构给提供给他们的不同的能力。

图1：架构的关注点

总的来说：架构是一个系统的核心，架构的目标是要平衡系统所有用户的关注点。一个系统的用户一般有客户、产品运营人员、产品开发人员、产品运维人员、项目经理、测试人员等，在做架构设计时，我们需要和这些用户进行沟通，和任何一方沟通有问题都可能导致在做架构设计时没有考虑到他们的利益关注点，导致架构的设计是有缺陷的。另外各个不同的用户的关注点可能是有冲突的，如产品运营人员更关注系统能够快速高效地推出新的特性，产品运维人员更关注系统的稳定可靠，当利益相关者的利益冲突时，架构师需要去平衡这些利益冲突。

我心目中理想的架构应该具备哪些因素？

图2:理想的架构所具有的因素

一、架构需要有明确的商业目标。

1、为什么需要明确的商业目标？

（1）架构的基础目标来源于商业目标。

架构是一种商业的解决方案，架构的基础目标是满足商业的需求。如果商业目标都没有想清楚，那架构的目标也不会清晰，目标不清晰，思路就不会清晰，思路不清晰也就谈不上设计好的架构了。

（2）明确的商业目标保证整个组织有统一的愿景和行动力。

组织中的商业和技术团队有了共同的商业目标后，才能一起更好地了为了一个相同的目标努力。商业团队和技术团队能根据明确的商业目标制定针对性非常强的计划，并且都信任对方能够达成计划的目标。

2、明确的商业目标包含的几个方面。

1、明确可衡量的商业目标。

商业目标一定要明确并且可以衡量，明确的商业目标才会有明确的架构目标，可衡量的商业目标才能够衡量架构对于商业目标的满足度。

2、商业目标达成度评价体系。

建立完整的商业目标达成度的评价体系，并把评价结果实时地反馈给商业和技术团队，这样每个成员都能很清楚地了解到架构针对商业目标有哪些满足，哪些不满足，这种透明度可以促进每个组织成员对于架构怎么能更好地满足商业目标的思考。

3、达成商业目标的关键风险和困难。

明确清晰地列出架构满足商业目标有哪些关键的风险和困难，并详细描述这些风险和困难以及可能对应的解决思路。

二、架构可以用简洁易懂的语言描述清楚。

好的架构都很容易让人理解并且豁然开朗的。

架构需要管理系统的复杂性和可变性，随着业务的发展和系统的演进，好的架构可以对需要变化的部分进行演进，不需要变化的部分不受任何负面影响。

管理系统复杂性的核心手段是进行抽象，抽象的关键是要有清晰明确的概念以及概念之间的关系。管理系统可变性的核心手段是把易变性和不变性进行隔离。

当我们能够把概念以及它们之间的关系都描述的清晰明确，那我们就能够用简洁易懂的语言描述清楚当前的架构。

当我们能够把易变性和不变性进行隔离时，那我们就能用简洁易懂的语言描述清楚随着业务的发展架构能够怎么去很好的演进。

三、架构需要有清晰的成长规划路径。

需求会时时发生变化，业务经过早期的培育后可能会有一个高速成长期，这样对架构就提出了很大的挑战，架构怎么样才能够很好地适应需求的变化以及应付业务的高速成长呢？这就需要在架构设计的早期对于这些情况出现时架构怎么去成长有一个明确的规划路径。

1、对于后续需求变化时的规划路径。

有一些新的需求往往会超出现有架构所能满足的能力，那架构势必需要进行调整，理想的架构的调整应该是成长型的，而不是重建型的。

2、对于后续业务进入高速成长期的规划路径。

业务进入高速增长期后，理想的架构是可以通过扩展来承载高速增长的业务。

三、架构需要对失败事件有强大的适应能力。

突发事故、bug无处不在，特别对于现在越来越大的集群来说，失败可以说是常态。架构需要专门对这些失败的情况进行设计。

好的架构会默认硬件和软件失败是IT基础设施的一部分，对于失败事件的处理是有弹性的，而不会在失败事件发生时只是被动无奈地接受。

1、对硬件失败事件的适应能力。

很多软件系统的设计通常都忽略硬件失败的情况。

如某台物理服务器突然掉电或者断网，那当前这台服务器上正在处理的业务怎么能不受影响地调整到其它服务器上执行呢？

如当写数据时某台物理服务器的磁盘满了，那怎么能够保证数据不丢失，业务不受影响呢？

类似于这种硬件失败的很多其它事件发生时该怎么处理？

好的架构有很好的弹性能力来处理硬件失败事件发生时下一步应该怎么走。

2、对软件失败事件的适应能力。

当某段代码抛出了异常后，整个业务的处理是否有回滚机制？

程序中有一个bug导致系统中的某个服务陷入死循环后，这种情况要怎么处理？

软件失败的事件的种类要比硬件失败的复杂的多，因为软件的失败事件往往是人导致的。

3、对于外部攻击事件的适应能力。

网络安全问题无处不在，前不久的勒索病毒就是一个典型的例子。架构上怎么去抵御外部的攻击，即便受到攻击怎么去保证关键资产和信息的安全？

四、强大的自动化运维能力

1、强大的自动化部署能力

（1）不管是物理机环境、虚拟机环境或者物理机和虚拟机共存的环境都能够支持自动化部署。

（2）某个开发或者测试人员，当需要环境进行测试时，随时都可以申请一套和设计生产环境等效的微小环境进行测试。

2、完善的系统健康度评价体系

当系统开始运行后会有各种各样的问题，需要有一套完善的监控度评价体系来评价业务的健康度、系统运行时环境的健康度等。当出现问题时，可以结合规则库、知识库等经验库来自动化处理，或者自动及时地通知对应的人员来进行处理。

五、架构需要有效的闭环反馈机制

早期的架构设计是建立在和各用户早期沟通的基础上，那个时候没有实际可运行的系统，获得信息很有可能不全甚至是错误的，在系统真正投入运行之前，再好的架构也都只是假设而已。

下图是经典的对用户需求理解偏差导致项目失败的例子：

图3:用户需求理解偏差导致项目失败

各用户对于自己的关注点是什么在项目的早期可能也不清楚，即便清楚在描述的过程中或者经过架构师理解后也有可能跟该用户的原始想法有偏差，所以偏差几乎不可避免，那怎么最大程度地去消除理解或者沟通上的偏差呢？只能通过和用户进行反馈和沟通，根据反馈的结果对架构进行调整，然后再进行反馈沟通，再调整，如此反复。所以和用户建立有效的闭环反馈机制非常重要。