架构随便聊聊.docxVIP

架构-任凭聊聊 　　所谓一千个架构师中有一千种“最好的架构”模式。 　　“架构”是我们这行业种一个很常见的词，表明其必定也是经受了很长的岁月打磨所构成的一个词。架构的这个词消灭的意义是什么？为了处理什么问题？只要把这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.可验证：一个好的框架需要考虑到各种特殊情况，并且是可以进行专项验证的。 ? 四、做架构中的误