阅读笔记--互联网架构：屡试不爽的架构三马车

经上网查找，互联网架构的演变

1 最初是前端一个web 加一个DB的结构

 

这种结构，web容易挂掉，业务就会终止，由于高可用的需求，出现了下面这样的架构

2 加了一个web，两个web之间是主备的关系，一个挂了，另一个来代替，用来解决高可用问题

 

3 之后发现这样的架构支持的访问量不够了，前端撑不住那么大的访问量，因为前端的访问量和DB的落库有大概是10比1的比例，前端访问10个，会有1个能够落库，所以随着访问量的增加，前端先扛不住了，这个时候主、备结构已经不能解决高可用的问题，所以在web前面加了一个ngx，作为负载均衡进行访问的转发，这个时候，web和web之间的主备关系就不存在了，在ngx进行转发的时候会有一个session保持的操作，再后来就出现无状态的概念，在两个web之间进行轮询，给谁都行

 

4当无状态的概念出来以后，web这一层就可以进行多次的横向扩展，这是第一次质的飞越

 

后来人们觉得一个ngx也会出问题，就设计了主、备结构的ngx

 

5 后来主、备ngx结构也不满足需求了，就在ngx前面加了一个lvs，lvs负责把请求转发给nginx

 

本篇文章所说的三架马车是指微服务、消息队列和定时任务。如下图所示，这里是一个三驾马车共同驱动的一个立体的互联网项目的架构。不管项目是大是小，这个架构模板的形态一旦定型了之后就不太会变，区别只是我们有更多的服务有更复杂的调用，更复杂的消息流转，更多的Job，整个架构整体是可扩展的，而且不会变形，这个架构可以在很长的一段时间内无需有大的调整。

微服务

微服务并不是一个很新的概念，在10年前的时候我就开始实践这个架构风格，在四个公司的项目中全面实现了微服务，越来越坚信这是非常适合互联网项目的一个架构风格。不是说我们的服务一定要跨物理机器进行远程调用，而是我们通过进行有意的设计让我们的业务在一开始的时候就按照领域进行分割，这能让我们对业务有更充分的理解，能让我们在之后的迭代中轻易在不同的业务模块上进行耕耘，能让我们的项目开发越来越轻松，轻松来源于几个方面：

1.如果我们能进行微服务化，那么我们一定事先经过比较完善的产品需求讨论和领域划分，每一个服务精心设计自己领域内的表结构，这是一个很重要的设计过程，也决定了整个技术架构和产品架构是匹配的，对于All-In-One的架构往往会省略这一过程，需求到哪里代码写到哪里。

2. 我们对服务的划分和职责的定位如果是清晰的，对于新的需求，我们就能知道需要在哪里改怎么样的代码，没有复制粘贴的存在少了很多坑。

3. 我们大多数的业务逻辑已经开发完毕，直接重用即可，我们的新业务只是现有逻辑的聚合。在PRD评审后，开发得到的结论是只需要组合分别调用ABC三个服务的XYZ方法，然后在C服务中修改一下Z方法增加一个分支逻辑，就可以构建起新的逻辑，这种爽快的感觉难以想象。

4. 在性能存在明显瓶颈的时候，我们可以针对性地对某些服务增加更多机器进行扩容，而且因为服务的划分，我们更清楚系统的瓶颈所在，从10000行代码定位到一行性能存在问题的代码是比较困难的，但是如果这10000行代码已经是由10个服务构成的，那么先定位到某个服务存在性能问题然后再针对这个服务进行分析一下子降低了定位问题的复杂度。

5. 如果业务有比较大的变动需要下线，那么我们可以肯定的是底层的公共服务是不会淘汰的，下线对应业务的聚合业务服务停掉流量入口，然后下线相关涉及到的基础服务进行部分接口即可。如果拥有完善的服务治理平台，整个操作甚至无需改动代码。

服务一定是立体的，不是在一个层次上的，如上图，我们的服务有三个层次：

聚合业务服务：高层次的串起来整个流程的具有完整业务形态的业务服务。和基础业务服务不同的是，这里是在完整描述一方面的业务，这个业务往往是由各种基础业务拼装组合起来的。和不同外部合作方的不同合作形式，给用户提供的产品的不同服务形态，都决定了聚合业务服务会有业务流程上的差异化，如果把此类服务下放到基础业务服务中，那么基础业务服务会有各种if-else逻辑（根据产品类型、用户类型进行各种if-else），随着业务的合作不合作，需求变动，基础业务服务会腐化得很厉害，为了避免这个情况，我们把变动的多的聚合业务逻辑放到独立的业务服务中。一般而言，聚合业务服务因为代表了独立的业务流程，它们之间是不会进行相互调用的，但是它们一定会调用大量的各类基础业务服务。在第一点里说的标有蓝色字体的a~d这些服务都是此类服务。这个层次的服务的业务逻辑更多是在表达业务流程的复杂性和差异性，不会涉及到具体怎么处理账户信息、账务信息、用户信息，不会涉及到怎么处理具体的投资人和借款人的交易。比如对于预约这类业务形态，它关注的是先要预约资产，然后再由系统进行自动投资，底层完全依赖于投资人交易服务来做整个交易的过程。

基础业务服务：某一个领域业务相关的服务。此类服务之间是允许相互调用的，比如投资人交易服务和借款人交易服务免不了需要和用户服务、资产服务、账户账务服务进行通讯做相关的用户信息查询、标的信息查询、记账等业务操作。之所以投资人交易服务和借款人交易服务定位为基础业务服务是因为，它们处理的是还是某一个具体方面的业务，并不是全流程，在这个抽象层次上，业务不是那么容易变动的，对于复杂的各种业务形态（比如预约交易、自动复投交易、等额本息交易）会在这些服务之上形成聚合业务服务。在第一点里说的标有绿色字体的e~k这些服务都是此类服务。在这个层次的服务虽然拥有大量的业务逻辑，但是其实已经享受到了很大层度的公共基础服务的重用了，而且和自己业务耦合较弱的额外逻辑往往没有在本服务中堆积，由更多专职的基础业务服务来承担了这部分逻辑。

公共基础服务：负责某一个方面的基础业务（没有什么领域业务逻辑在里面），可以是自治的处理某一个方面的基础业务，也可以和外部通讯实现某一个方面的功能，服务之间是不会相互调用的，但是会被聚合业务服务和基础业务服务调用。在第一点里说的标有橙色字体的l~n这些服务都是此类服务。如果以后和外部的合作有变动，因为我们已经定义了对外的服务契约，可以轻易替换这个服务来更换合作的第三方，系统其余的地方几乎不需要修改。所有的三方对接都建议独立出公共基础服务，如果同一个业务对接多个三方渠道，比如推送对接了极光和个推，甚至公共基础服务还可以由一个抽象聚合的推送服务，下面再路由到具体的极光推送和个推推送服务。