好多年了，第一次发表文章还是工作第二年，7年过去了，居然又回来写文章，也是没想到。当初对自己的期望也算实现了吧，也做到了架构，不过现在岗位更偏管理。
架构就像修桥一样，从一个点到另一点，是打通两端之间的阻碍解决方案。但是架构不是普通的解决方案，是合理的解决方案。
打通两端这个比喻并不是合适的例子，它是架构目的的部分，架构就是合理的解决方案。举这个例子，是想说明，架构不能不落地。具体的说就是如果需要做一个业务
（很多技术对业务理解就是产品提的需求，我的理解是任何需要抽象到软件中的运行流程，比如开发mq，那么生产，消费，队列就是业务，万事都是业务），业务方与普通研发之间存在业务
与技术的阻碍，即业务方不懂得技术，普通研发技术水准，经验，意识，分析需求能力，抽象能力不足。例如业务方（继续强调，万事皆可业务，不是说crud的业务才叫业务，任何事物行为都可以叫业务）不了解技术，天幻乱坠的提了很多杂乱无章的需求，研发基于业务上来就做，
做了一套系统满足业务方，但是考虑的太少，抽象能力不够，造成后期维护成本增加（出现问题最多的点），牵一发动全身，并行开发困难，系统不足以支撑当前的业务量，系统在特定环境无法完成工作等问题。
架构其中一部分的目的就是打通业务方与研发之间的阻碍（阻碍这个词用的不好，有点只可意会不可言传的意思，总之就是两边直接走是走不过去的，有障碍），总之是得基于现有情况得能让团队落地，高高在上的架构团队无法实现，不能说不是架构，只是对于团队是一个毫无意义的架构，只能说是一种存在于理想的yy，当然yy也是好事情，万一哪天实现了呢。所以没有最好的架构，只有最合适的架构。打通这两个点的解决方案，就是架构的范畴。上面也说了，如果研发直接上手不是不能完成业务，研发直接根据业务逐条完成，这是一种是解决方案，但不是我们所说的架构。架构是指合理的解决方案。不合理解决方案不能称之为完成业务。
要完成这个业务域的方案是什么呢，给出这个合理方案的过程就是架构过程，就是我们说的架构。即现实业务抽象到软件世界，为现实到软件的抽象过程。在软件世界基于业务与现有情况，设计合理的软件解决方案，则为架构设计。方案本身则为架构。
架构过程是怎样呢
1.基于业务抽象，即业务在软件世界中需要的事物，架构师必须具备高水准的抽象能力。
2.设计事物的合理关系，即事物设计事物的合理协作或者说叫做关系。
3.基于协作关系，合理分层。
4.基于业务产生的事物与协作抽象出层与层的交互规则，业务流程中的共性规则也要落到系统中。多说两句软件产生并不是因为技术，是因为技术，技术人不要看不起业务，本身技术存在的价值就是因为业务。比如做中间件的团队，技术普遍比业务研发的技术好，但是也没必要觉得业务研发每天就是crud，大家其实都是在做业务，只不过中间件团队的业务本身就比较有规则，更有共性，可以说是已经经过很多人抽象过的业务了。如果让中间团队去根据市场的业务去设计一套系统，肯定是没有研发团队设计的好，大家其实都是做业务的，只不过是业务的目的不同。继续说为什么规则重要，因为没有规则就没办法统一管理，比如我想对整个系统做个xxx，或者我要针对某一层做xxx，假如么有系统级的规则，没有层与层之间的交互规则，则没有办法完成。很多人在做系统架构的时候不去做这一层规则的抽象，前期还好，后期问题会无限放大，没有哪个系统是不需要统一做xxx的。再者，建立规则是扩展的前提。比如一个业务（业务可以无限小也可以无限大，它可以是业务方的一个需求，也可以是代码运作的一段流程），我要做扩展，发现所有代码没有任何规则，a,b,c好几种情况，都不同。扩展满足了a就不能满足b，满足b就不能满足c，这扩展没办法做了。合理的做法是a,b,c如果是一类业务，则对业务做抽象，提炼出抽象的规则（交互规则，业务流程即运行规则等，规则具有通用性，可以看做为业务运行的本质，需要对业务有高度的抽象能力与对业务的未来的预知能力，规则必须满足未来无论业务如何变化，在某一个范围内的执行逻辑是不变的），那么我们就可以基于这个不变的规则去做某一个位置的扩展，因为知道无论什么情况，任何规则范围的一切事物都遵循这套规则，只要基于这个规则的扩充，就能同时满足适用于这套规则的所有位置。比较简单的例子，例如spring，最基本的规则只要是加上spring注解范围的类就在spring的管理范围。spring只要发现有spring的注解，就可以做各种扩充，比如对象的创建，放到ioc，di等。想想如果没有这套规则呢，spring没有定义注解范围，就不会知道哪些是自己管理的类，需要ioc，di（ioc，di可以看做是规则之上做的扩充）等操作。spring mvc本身就是一套mvc规范的实现，它的实现就是建立各种规则。一个方法调用的规则是首先类上有注解，加到ioc中，成员变量有注解，则去ioc中寻找，有的话就di，没有就报错。只有满足这套规则，才能完成类与类的方法调用业务。spring如果做成没有规则，任何注解都可以放到ioc中，会怎样？spirng做不下去了啦，100个人写了100种注解，spring怎么知道这100种注解都是做什么的，哪些放到ioc，哪些情况需要di。这个就是a，b，c因为没规则所以无法扩展的例子。所以spring对软件开发类的创建，调用这块业务中设计到的动作，事物做了抽象，抽象出了controller，compment之类的注解。比如controller注解，当我需要做一段关于请求处理的业务的时候，我因为知道所有可接收请求的类的方法必然都有controller的注解，那么我可以基于这个规则，找到所有controller注解的类，在这些类初始化的时候或者进入方法开始之前，之后做各种业务。这个规则抽象还比较具体，可能更多的时候是对流程的抽象，比如完成一件事的过程需要1,2,3,4，但是具体到场景1,2,3,4虽然做的是同一类的事情，实现起来却存在差异。那么1,2,3,4则是抽象规则，虽然有不同的实现方式，但是没有方式必然是1到2,2到3,3到4,4到5,，那么我扩展的业务可以基于这个规则去做，比如我要针对调用1之前做某些业务，因为所有过程都是1开始的，那么这个业务就会影响到1,2,3,4这种业务的所有位置。总之没有规则，就没扩展，因为你根本不知道各个位置都怎么做的，一个位置能跑通，但是换个位置就行不通了。
5.架构是一个平衡，在时间，复杂度，研发成本，维护成本，性能，体验等多方面做平衡。这一点非常重要，一个不能基于现实情况的架构，2个人3天做一个支付宝，赔本买卖（能用mysql非得上oracle），团队开发排查问题困难（一个简单的业务非得拆成几百个服务），卖20w结果研发成本50w，每天就2个请求上各种没人看得懂的设计只能自己维护，花一个月做了一个用户根本不care的优化等问题。不做平衡很难落地，就算落地也是一堆的后续问题。