在软件开发领域，自从架构这个词被广泛传播之后，产生的架构模式也非常多，架构关注点也在增加。但回到“道”的层面，架构的定义或者说本质还是：
架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
————摘自《百度百科》
很多做业务功能的增删改查开发感受到无趣的小伙伴常把做架构想象成一片乐土，没有嘈杂的业务声音干扰，可以专心做一番牛X的技术。会把架构单纯的理解成，牛X的性能、牛X的TPS、高可用，支撑了多少PV等等。但是其实这些只是架构很小的一部分，并不是全部。在互联网时代之前都是C/S程序的天下，那个时候并没有对性能等有像现在这样的关注度，但是就已经有架构之说了。 世上本无架构，只是由于团队越大越需要对整体的规则做约定，好让大家往同一个方向发力，避免各自为战，产生大量的内耗，所以才逐渐形成了架构。这条路就是“世上本无路，只是因为走的人多了变成了路”。
为什么说一个软件架构是很重要的呢？当我们的团队人数只有2、3个人，甚至只有1个人单枪匹马的情况下，可能架构凸显的作用不是那么的明显，但是如果团队大了之后相信下面的这些现象会比较常见：
新上一个系统，往往不是独立存在的，一般都需要与现存的系统进行交互，而需要集成交互的地方可能还很多，哪些集成是本系统需要实现的？同时，一般会划分为多个阶段开发，怎样界定系统的边界呢？
软件系统是一个由多个模块组成的整体。因此当上游开发与我们负责的模块衔接老是出问题时，自己再做更多的努力也无法扭转上游模块的质量差带来的负面效果。（我想大家这时候肯定是抓狂的。）
每次看到别人写的代码，老觉得自己来写的话肯定不会这么写。比他写的更好。（我们做技术的，自我感觉良好是个常态：）。）
在某些场景下，自己脑子里有多套方案来实现，但是对孰优孰劣没太大感觉，最终基本上就是拍脑袋选了一个。
某块代码维护的次数多了，特别是中间由多个人接手过后，代码风格各异，难以理解。
相似的代码在好几个地方出现，特别是一些非业务性的代码，比如日志处理等。再甚是在大型的分布式系统中，不同子程序使用了不同的同类型中间件，同样导致维护成本大增。
在2个相依赖项目边界处的设计产生了分歧，并且站在各自的角度看都有道理。
任何事物都是有两面性的，并不是说上面的这些问题，我们通过架构就要往另外一个极端去走。比如在大型的分布式系统中，不同子程序的确有必要在某些时刻选择同类型的其它中间件。如Kafka和RabbitMQ虽都是MQ，但在特定的场景下能发挥的价值是无法相互替代的。
所以我们做架构有一点也是比较重要的，就是去Balance，选择一个投入产出比最优的方案。关于这点第四段中会多说几句。
除此之外，架构的主要目的是为了让大家往同一个方向，在同一个标准之上去发散扩张。一是把控硬性的下限标准，提高整体的最短版，二是提高上限水平位，也就是天花板位置，提供更大的发展空间。好比造一幢大楼，把框架结构设计好搭好，让大家形成一个共识，什么是承重墙不能破坏，什么是创变空间可以自定义。在这样的基础下各自发展。这个看上去是个限制，但却是做架构最重要的任务，所谓再多的文档，再多的最佳实践都比不上一条约束。降低复杂度、降低理解难度，是实实在在的收益。最怕的就是凭空假设带来的过度浪费。
更甚之，我们做架构追求的理想国度是一个大家拥有一致共识的世界，架构是大家都像吃饭喝水这样习以为常的习惯。去理解或者接手其它人负责的项目的时候就好像是自己写的一样。这个时候就消灭架构了，就好比现在没有人会教你如何吃饭一样。（就当YY一下吧：）。）
上面提到更多的是做架构的目的，那么要做好架构，主要就是要做好抽象，做抽象的方式是类比，做类比的方式可以使用用例图。所以建议大家多画图，通过画图来将大脑中抽象的结果直观的体现在前面，再来进一步分析合理性。主要推荐2种图的类别，一种就是前面提到的用例图。如下图：
另外一种是鲁棒图，如图：
整个过程的主要目的是：
描述其与外部实体（系统和最终用户）的交互。
标识系统和外部实体间的信息和控制流。
之前有一篇专门整理图的文章《软件开发中会用到的图》，有兴趣的小伙伴可以在我公众号中查阅。
理想的世界里，我们程序的边界设计恰好匹配于业务边界。然而我们作为工程师首先要承担业务需求的压力，只能挤时间去做这些非业务性工作。也因此老项目的业务边界也并不总是如新项目那样明晰。
这意味着做任何架构的改动要考虑优先级，特别在拆分业务领域之前认真地思考业务的边界。排定优先级，考量拆分的收益与风险。划分业务的边界，则需要更多的思考拆分后的未来将如何沟通协作，然后再考虑技术因素。在技术因素前，主要考量这几点：
是否拥有独立的团队来维护，以及是否拥有发展为一项独立业务的潜力。（非必要的情况下，一定要避免共享内核的开发方式）
围绕领域而非 feature，有明确的维护团队，避免过于细粒度。
拆分或者组合之后，能否改善现有的协作流程。
能否帮助区分核心、非核心业务，改善稳定性。
上面这些完成了之后，便是选择合适的中间件、技术框架来满足技术层面的要求，这个的选拔主要以下面几点来考量：
如果是直接引入第三方的中间件的话，成熟度如何？是否有大公司在用？（有大公司的口碑背书的肯定大大加分）
近期的社区活跃度如何？（用于考量是否有更多的人在一起踩坑，降低各自遇到坑的数量和概率）
硬指标，当前场景的硬性要求是否满足。如性能、对关键部分或者未来的可扩展性等。
软指标，复杂度、可维护性等。这里可以罗列几个竞品的优劣势。
最重要的是要自己去亲自验证上面的几点，并且做一定的模拟工作。
如果曾经用过或者有其中一部分的经验可复用，这是加分项，毕竟在使用的过程中才发现hold不住它，那是灾难性的！
之前有听到过一句话，概括的很精辟。好的架构必须需要贴合业务，那么把业务+技术演变成一个数学公式来表达可以理解为：2个数字的和等于10，求如何组合能得到最大的乘积。那不是3*7，也不是4*6，而是5*5。
所以架构不是生搬硬套，为了架构（搞事情）而架构，赶时髦，或者说装X。我们应避免通过个人的主观意愿来主导。比如自己觉得某个中间件好，就”拿着锤子到处找钉子“，这一敲下来，看着不错，但是带来的成本和风险被忽略了。可能有更好的解决方案，或者完全没必要在当下敲这一钉子下去。
好的架构需要评判投入产出比，收益更高的就是更好的架构，就如下图的公式。产出可以理解为我们因此获得的好处（诸如可靠性、安全性、可扩展性、可维护性、可伸缩性、性能等），成本是我们改造花费的投入，如人力物力和时间。特别注意的是风险这点，是很重要也是很容易被大家忽略的一点，是起到指数级作用的。选择的方案再好，如果都是一些hold不住的技术，那么风险就是无穷大，导致减号右侧无限趋近于0，最终的结果就是收益是负数，投入的成本打水漂，甚至还要加上其它额外的付出。
上面提到的这些关注点都是架构师的职责，另外特别重要的一点是，架构师必须要是个有追求的“好码农”！！！（划重点）。软件架构师不像建筑师，其面对的本身是一个抽象的事物，如果再脱离了实操，这基本和纸上谈兵无异。所以实际工作中的难点、要点都得清楚，并且能够给出解决方案或者方向。另外只有熟悉实操才能更准确的评估成本
成为了一个真正的“好码农”就向架构师迈出第一步了。而后呢，需要不断以深 --> 广 --> 深 --> 广的节奏去开疆扩土，扩大自己的知识领域，当然需要以贴近当前工作内容的知识为主，这是第二步。到了这还没完，还有打造三板斧：业务能力、沟通能力、个人魅力。
题外话，在国内，纯技术的架构师没有应用型的架构师吃的开。所以此文皆以应用型架构师的职能要求为参考。
回到文章开头，架构的表现形式有很多，从本质上单体应用的架构设计思想和分布式系统是一致的，所谓服务化其实也是模块化的思想，只是维度的不同，导致用到的一些工具或者环境不同，但这都是“术”层面的东西。光学这些招数，永远也学不完。架构之路漫长，继续前行，共勉。
作者：Zachary_Fan
出处：https://blog.51cto.com/4596298/2147603
如果你想及时得到个人自写文章的消息推送，欢迎扫描下面的二维码~。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
