聊聊架构设计作些什么来谈如何成为架构师

　　

　　在软件开发领域，自从架构这个词被普遍传播以后，产生的架构模式也很是多，架构关注点也在增长。但回到“道”的层面，架构的定义或者说本质仍是：

　　架构，又名软件架构，是有关软件总体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

　　————摘自《百度百科》

　　不少作业务功能的增删改查开发感觉到无趣的小伙伴常把作架构想象成一片乐土，没有嘈杂的业务声音干扰，能够专心作一番牛X的技术。会把架构单纯的理解成，牛X的性能、牛X的TPS、高可用，支撑了多少PV等等。可是其实这些只是架构很小的一部分，并非所有。在互联网时代以前都是C/S程序的天下，那个时候并无对性能等有像如今这样的关注度，可是就已经有架构之说了。 世上本无架构，只是因为团队越大越须要对总体的规则作约定，好让你们往同一个方向发力，避免各自为战，产生大量的内耗，因此才逐渐造成了架构。这条路就是“世上本无路，只是由于走的人多了变成了路”。

　　为何说一个软件架构是很重要的呢?当咱们的团队人数只有二、3我的，甚至只有1我的单枪匹马的状况下，可能架构凸显的做用不是那么的明显，可是若是团队大了以后相信下面的这些现象会比较常见：

　　·新上一个系统，每每不是独立存在的，通常都须要与现存的系统进行交互，而须要集成交互的地方可能还不少，哪些集成是本系统须要实现的?同时，通常会划分为多个阶段开发，怎样界定系统的边界呢?

　　·软件系统是一个由多个模块组成的总体。所以当上游开发与咱们负责的模块衔接总是出问题时，本身再作更多的努力也没法扭转上游模块的质量差带来的负面效果。(我想你们这时候确定是抓狂的。)

　　·每次看到别人写的代码，老以为本身来写的话确定不会这么写。比他写的更好。(咱们作技术的，自我感受良好是个常态：)。)

　　·在某些场景下，本身脑子里有多套方案来实现，可是对孰优孰劣没太大感受，最终基本上就是拍脑壳选了一个。

　　·某块代码维护的次数多了，特别是中间由多我的接手事后，代码风格各异，难以理解。

　　·类似的代码在好几个地方出现，特别是一些非业务性的代码，好比日志处理等。再甚是在大型的分布式系统中，不一样子程序使用了不一样的同类型中间件，一样致使维护成本大增。

　　·在2个相依赖项目边界处的设计产生了分歧，而且站在各自的角度看都有道理。

　　任何事物都是有两面性的，并非说上面的这些问题，咱们经过架构就要往另一个极端去走。好比在大型的分布式系统中，不一样子程序的确有必要在某些时刻选择同类型的其它中间件。如Kafka和RabbitMQ虽都是MQ，但在特定的场景下能发挥的价值是没法相互替代的。

　　因此咱们作架构有一点也是比较重要的，就是去Balance，选择一个投入产出比最优的方案。关于这点第四段中会多说几句。

　　除此以外，架构的主要目的是为了让你们往同一个方向，在同一个标准之上去发散扩张。一是把控硬性的下限标准，提升总体的最短版，二是提升上限水平位，也就是天花板位置，提供更大的发展空间。比如造一幢大楼，把框架结构设计好搭好，让你们造成一个共识，什么是承重墙不能破坏，什么是创变空间能够自定义。在这样的基础下各自发展。这个看上去是个限制，但倒是作架构最重要的任务，所谓再多的文档，再多的最佳实践都比不上一条约束。下降复杂度、下降理解难度，是实实在在的收益。最怕的就是凭空假设带来的过分浪费。

　　更甚之，咱们作架构追求的理想国度是一个你们拥有一致共识的世界，架构是你们都像吃饭喝水这样习觉得常的习惯。去理解或者接手其它人负责的项目的时候就好像是本身写的同样。这个时候就消灭架构了，就比如如今没有人会教你如何吃饭同样。(就当YY一下吧：)。)

　　上面提到更多的是作架构的目的，那么要作好架构，主要就是要作好抽象，作抽象的方式是类比，作类比的方式可使用用例图。因此建议你们多画图，经过画图来将大脑中抽象的结果直观的体如今前面，再来进一步分析合理性。主要推荐2种图的类别，一种就是前面提到的用例图。以下图：

　　

　　另一种是鲁棒图，如图：

　　

　　整个过程的主要目的是：

　　·描述其与外部实体(系统和最终用户)的交互。

　　·标识系统和外部实体间的信息和控制流。

　　最后附一篇以前整理的《软件开发中会用到的图》的文章地址，有兴趣的同窗能够扩展阅读下：https://www.cnblogs.com/Zachary-Fan/p/developdiagram.html。

　　理想的世界里，咱们程序的边界设计刚好匹配于业务边界。然而咱们做为工程师首先要承担业务需求的压力，只能挤时间去作这些非业务性工做。也所以老项目的业务边界也并不老是如新项目那样明晰。

　　这意味着作任何架构的改动要考虑优先级，特别在拆分业务领域以前认真地思考业务的边界。排定优先级，考量拆分的收益与风险。划分业务的边界，则须要更多的思考拆分后的将来将如何沟通协做，而后再考虑技术因素。在技术因素前，主要考量这几点：

　　·是否拥有独立的团队来维护，以及是否拥有发展为一项独立业务的潜力。(非必要的状况下，必定要避免共享内核的开发方式)

　　·围绕领域而非 feature，有明确的维护团队，避免过于细粒度。

　　·拆分或者组合以后，可否改善现有的协做流程。

　　·可否帮助区分核心、非核心业务，改善稳定性。

　　上面这些完成了以后，即是选择合适的中间件、技术框架来知足技术层面的要求，这个的选拔主要如下面几点来考量：

　　·若是是直接引入第三方的中间件的话，成熟度如何?是否有大公司在用?(有大公司的口碑背书的确定大大加分)

　　·近期的社区活跃度如何?(用于考量是否有更多的人在一块儿踩坑，下降各自遇到坑的数量和几率)

　　·硬指标，当前场景的硬性要求是否知足。如性能、对关键部分或者将来的可扩展性等。

　　·软指标，复杂度、可维护性等。这里能够罗列几个竞品的优劣势。

　　·最重要的是要本身去亲自验证上面的几点，而且作必定的模拟工做。

　　·若是曾经用过或者有其中一部分的经验可复用，这是加分项，毕竟在使用的过程当中才发现hold不住它，那是灾难性的!

　　以前有听到过一句话，归纳的很精辟。好的架构必须须要贴合业务，那么把业务+技术演变成一个数学公式来表达能够理解为：2个数字的和等于10，求如何组合能获得最大的乘积。那不是3*7，也不是4*6，而是5*5。

　　

　　因此架构不是生搬硬套，为了架构(搞事情)而架构，赶时髦，或者说装X。咱们应避免经过我的的主观意愿来主导。好比本身以为某个中间件好，就”拿着锤子处处找钉子“，这一敲下来，看着不错，可是带来的成本和风险被忽略了。可能有更好的解决方案，或者彻底不必在当下敲这一钉子下去。

　　好的架构须要评判投入产出比，收益更高的就是更好的架构，就以下图的公式。产出能够理解为咱们所以得到的好处(诸如可靠性、安全性、可扩展性、可维护性、可伸缩性、性能等)，成本是咱们改造花费的投入，如人力物力和时间。特别注意的是风险这点，是很重要也是很容易被你们忽略的一点，是起到指数级做用的。选择的方案再好，若是都是一些hold不住的技术，那么风险就是无穷大，致使减号右侧无限趋近于0，最终的结果就是收益是负数，投入的成本打水漂，甚至还要加上其它额外的付出。

　　

　　上面提到的这些关注点都是架构师的职责，另外特别重要的一点是，架构师必需要是个有追求的“好码农”!!!(划重点)。软件架构师不像建筑师，其面对的自己是一个抽象的事物，若是再脱离了实操，这基本和纸上谈兵无异。因此实际工做中的难点、要点都得清楚，而且可以给出解决方案或者方向。另外只有熟悉实操才能更准确的评估成本

　　成为了一个真正的“好码农”就向架构师迈出第一步了。然后呢，须要不断以深 -- 广 -- 深-- 广的节奏去开疆扩土，扩大本身的知识领域，固然须要以贴近当前工做内容的知识为主，这是第二步。到了这还没完，还有打造三板斧：业务能力、沟通能力、我的魅力。

　　题外话，在国内，纯技术的架构师没有应用型的架构师吃的开。因此此文皆以应用型架构师的职能要求为参考。

　　回到文章开头，架构的表现形式有不少，从本质上单体应用的架构设计思想和分布式系统是一致的，所谓服务化其实也是模块化的思想，只是维度的不一样，致使用到的一些工具或者环境不一样，但这都是“术”层面的东西。光学这些招数，永远也学不完。架构之路漫长，继续前行，共勉。

​