架构随聊

一、架构的定义

所谓一千个架构师中有一千种“最好的架构”模式。

　　“架构”是我们这行业种一个很常见的词，表明其必然也是经历了很长的岁月打磨所形成的一个词。架构的这个词出现的意义是什么？为了解决什么问题？只有把这2个问题想明白了，才能设计出一个良好的项目架构。

　　我认为 架构类似于画房屋设计图，在刚开始我们盖一层楼的小房子的时候，拍拍脑门想一下，脑子里有个大概的样子就开始动工了，想怎么盖就怎么盖，大部分情况下也都不会出现。但是当你要盖一个大楼，这时候拍拍脑门的方式虽然有可能还能管用，但是由于没有经过深思熟虑的多方考量，建造出来的必然是问题重重。另外建造大楼和盖个一层楼的小屋所需的团队规模肯定是不同的，每个人心中的标准不同，如果没有一个统一的规范，最后的结果可想而知。所以架构就是定规则做限制，是在权衡各方得与失之后的一个“最合理决策”，由它来指导团队中的每个人思想层面上的一致，使得最终的产品达到像由一个人做出来的一样。另外还有控制复杂度、提高团队协作力、降低成本等等作用。

　　在软件开发中，架构的意义不单单是为了让团队达成一致，因为我们工作的本质是为了做出更好的支撑业务发展需要的软件产品，所以架构也是基于业务的架构。我认为一个好的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。我相信大部分在中小型公司呆过的人应该都经历过被业务推着走的时代，每天焦头烂额的这里卡了，这里挂了，这里报错等等问题。当我们遇到这些问题的时候是时候花成本来考量当前的架构是否存在问题？

二、如何开始设计一个架构

做架构的最重要的一点就是上面说的贴合业务，任何不基于业务做异想天开的架构都是耍流氓~

　　架构不是像平常写代码一样，对就是对，错就是错，它并无对错之分，是一个取舍的过程。当我们从0开始做架构的时候，的确是比较困难。虽然万事开头难，但是一个好的开始相当于成功了一半，会给我们接下去的工作打下结实的基础。　

　　下面来阐述一下笔者个人是如何从头开始做一个架构的，供大家参考学习：

　　1.架构是一个整体--> 部分的过程，先得明确整个公司/组织对外提供的服务是什么？这是最上层的战略架构，这个基本是一旦确定就很难甚至无法更改了。

　　2.给每个部分（比如SOA的某个服务）划分解决方案。比如根据公司的组织架构或者产品等。

　　3.找到每个解决方案的核心功能和支撑功能。并形成一个业务总览图

　　4.分久必合，合久必分，结合当前的实际资源情况做出最终的决策，这是整个过程中最耗时的点，它决定着架构的复杂度和开发成本。方式上包括但不限于抽出可重用的功能、功能的组合、拆分粒度更细的功能提高可重用性等等。这一切的决策都要以“恰到好处”为宜。千万不要盲目的跟从微服务之风！千万不要盲目的跟从微服务之风！千万不要盲目的跟从微服务之风！重要的事情说3遍。服务粒度越细，调用链路越复杂，带来的开发成本是否适合团队，是作为一个架构师需要着重考量的点。

　　5.确立每个功能块之间的协作方式，包括但不限于通讯方式，通讯协议，依赖关系等。

　　6.最后要把这些形成最终的架构总览图，这样能够帮助站在一个更高的角度去考虑架构的演变问题。如果是针对现存项目重新做架构，那么需要把现有项目架构梳理出来，作为我们上面思考过程中的一部分参考信息。

三、一个好架构的特点

首先从心态上必须要有工匠精神，因为软件架构和造房子还是有不同的，它不是一开始就一步到位的，好的设计肯定需要经过反复的修改，从简单到复杂的循环验证，不断的打磨。

　　方向上我认为分以下几个点：

　　1.文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。

　　2.高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

　　3.安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

　　4.可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。

　　5.快速迭代：拥抱变化，占领战略先机。

　　6.高度自治：为了更好支撑第4点和第5点的，每个功能能够高度自治带来的好处是可以快速迭代，并且不管是功能迭代还是技术迭代所对整个系统的影响降到最小。

　　7.高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

　　8.可验证：一个好的框架需要考虑到各种特殊情况，并且是可以进行专项验证的。

四、做架构中的误区

做任何事的时候需要不断的跳出原来的思维角度重新审视，这样才能避免陷入泥潭。列出几个我能想到的误区：

　　误区1——架构专门由架构师来做，业务开发人员无需关注：架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也由自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会由崩塌的风险。所谓“千里之堤，溃于蚁穴”。

　　误区2——架构师确定了架构蓝图之后任务就结束了：架构不是“空中楼阁”，最终还是要落地的，但是架构师完全不去深入到第一线怎么知道“地”在哪？怎么才能落的稳稳当当。

　　误区3——不做出完美的架构设计不开工：世上没有最好架构，只有最合适的架构。我们需要的不是一下子造出一辆汽车，而是从单轮车 --> 自行车 --> 摩托车，最后再到汽车。想象一下2年后才能造出的产品，当初市场还存在吗？

五、结语

架构之路任重而道远。程序设计和架构设计是互通的，每个人都可以从设计好一个程序往设计好一个系统架构前进。如果现在还无从下手的，我推荐大家可以从领域驱动设计这个概念入手，这是由业务为导向的设计方式，可以对培养设计出落地的架构有很大的帮助。本人目前也正巧在写如何一步一步用DDD设计一个电商网站系列，希望可以给大家一些思路和启发。最后引用“俞军”一句名言，我们作为架构师要有“怀疑精神：自我迭代”的心。