单体架构,分布式,SOA,和分布式的区别和选择

一:应用架构的演变

1.单体架构

简单来说我们以前传统的应用的就是单体架构,即所有的模块，组件等都在一个应用中应用最终打成一个(war,jar)包使用一个容器(Tomcat)进行部署，通常一个应用享用一个数据库。

 

 1.1单体架构的优缺点

        优点

        a.易开发,架构简单,技术成本低

        b.易于测试:所有功能在一个项目,方便测试

        c.易于部署:一个Tomcat就可以实现部署,简单方便

        缺点

        a.代码臃肿不方便开发维护(代码可读性差)

        b.代码编译系统启动变慢

        c.系统扩展性能变差(牵一发而动全身)

        d.无法针对某一个业务做扩展(集群)

        e.对大数据量,高并发量的处理不占优势

        f.技术选型单一

        g.模块/业务耦合度高

1.1单体应用于集群

在单体架构中，为了提升应用的并发作业能力和防止应用的单节点故障(一个Tomcat挂了，应用就挂了)我们通常会对应用做集群，这里的集群指的是把应用进行复制多个相同的应用一起工作来提高作业能力，多个应用做的是相同的事情。就如同我们生活中的场景“收银”,一个收银台不足以支撑超市大量客户的结账流程，所以需要多个收银台同时工作，多个收银台都是做的相同的收银工作，这就是集群.

当我们的应用做了集群，那么就会存在多个应用节点，多个应用将会暴露多个访问地址(ip:port)，那客户端是不知道该访问哪个应用节点的，这个时候我们就需要有一个请求分发的功能的组件(负载均衡器)将客户端的请求相对平均的分发多个应用节点上，这就是负载均衡，这个做请求分发的组件就是负载均衡器，如下图：

这里的Nginx就是一个负载均衡器，它可以按照某种算法(轮询,ip_hash等等)将请求路由到不同的后端服务器上，同类型的负载均衡器如“HAproxy”，“LVS”等，这里不展开讨论。负载均衡算法如：轮询，随机，权重。  

小结

当我们的单体项目没法支撑高并发的时候就可以做集群,加入负载均衡器来提升应用的作业能力,甚至我们也可以在数据库层也做集群(如主从复制)，这样的架构有一定的并发处理能力，也能满足一定的复杂业务需求，但是就应用本身而言任然是单体结构，仍然有其不足之处，如：

        a: 项目本身任然是单体，代码依然臃肿

        b: 面对海量数据数据库会成为性能瓶颈(需要分库分表)

        c:持续交互能力差，代码臃肿，业务复杂，开发维护时间长，新人入手成本高。

所以当单体应用不能满足复杂的业务和海量的数据时,我们就需要考虑其他架构

2.分布式和SOA

2.1.分布式架构

将上面的案例映射到我们的应用程序中也是一样的道理，当一个Tomcat负担不起系统中的所有业务的时候，我们可以按照业务把应用进行拆分成多个小的应用，每个小应用都用一个Tomcat去运行，每个小应用都是单体架构，每个应用只需要关系自己的业务即可，应用之间通过API相互调用.

当然如果某个子系统压力依然很大，可以单独对该子系统再做集群，所以分布式和集群并不冲突

总结一下什么是分布式 ：分布式就是将应用按照业务进行拆分成多个子应用，多个子应用部署在不同的服务器中，多个子应用组成一个完整的系统，所有的子系统一起工作相互通信相互协调才能完成最终的业务流程，缺一不可, 简单理解: "多个人在一起做不同的时候但是做的是一件完整的事"  

2.2. 面相服务的架构SOA

SOA是面向服务的架构,它的思想是每个子应用可以通过网络通信协议向其他子应用提供服务或者消费服务，SOA也是分布式架构，我们可以简单的理解为SOA把分布式架构划分成表示层和服务层，服务层中包含了业务逻辑和相关流程，只需要对外暴露服务即可，表现层负责处理和页面的交互。这样的划分好处在于系统之间调用的方便性，如用户子系统只需要调用订单子系统的服务层即可完成应用之间的通信。这样的结构划分提高了应用的重用性，业务逻辑也变得可组合。如图：

 SOA架构中有重要的两个角色，服务消费者(Consumer)和服务提供者(Provider)即服务调用者和服务被调用者，这样的架构优点有：

        a.模块差分,使用API通信,降低模块之间的耦合度

        b.项目拆分多个子应用,每个子应用业务简单,代码简单,容易维护和开发

        c.不同技术人员可以扶着不同的子应用

        d.提高服务之间的重用性，业务逻辑可组合。

缺点:

        a.服务之间的API接口开发增加了工作量

        b.SOA服务之间的网络通信调用对性能有一定的影响(尽管很小)

        c.相对于单体应用来说，技术,人力成本较高。

        d.部署和运维相对麻烦

3.微服务架构

3.1什么是为服务

微服务是在SOA架构上的一种发展,简单来说微服务就是把单一的应用进行差分,差分成多个微小服务,每个服务独立运行,每个服务只需要专注一个业务即可,并且每个服务都可以有自己的数据库,多个微服务之间相互配合完成整个系统的业务,这就是微服务.如图

微服务的特点: 

        a.由多个服务组成的完整系统

        b.每个服务都是独立的,有自己的进程

        c.服务之间使用HTTP协议

        d.不用服务之间可以用不同的语言进行编写

        e.不同服务之间数据库选择多样性

        f.微服务是一个分布式系统

3.2微服务优缺点

优点:

        在项目规模较大的时候，相对于单体应用来说，微服务具备很多优点:如

        a.单个服务业务简单，代码简单方便开发维护

        b.服务之间无耦合,服务之间升级维护互不影响

        c.轻量级HTTP通信机制，使得的不同的服务可以采用不同的编程语言

        d.微服务有极强的扩展能力,业务量大的服务可以再次拆分服务，也可以进行集群部署，剔除服务也很方便

        e.更大的系统负载能力和容错能力(集群)
        f.对于开发人员来说,通常只需要关注单一服务,新员工上手也比较快

        g.微服务架构对现在流行的敏捷开发支持优化

微服务缺点

        a.分布式事务 ：服务通信机制增加了事务的复杂性，架构师要选择合适的分布式方案(CAP理论)

        b.部署麻烦 ：微服务众多，部署麻烦，需要借助容器技术和自动化部署工具，这又增加了开发人员的学习成本。

        c.技术成本高 ：微服务架构本身比较复杂,技术成本高，开发人员需要花更多的时间学习相关技术。

        d.服务通信对性能的损耗 ： 微服务架构一定要考虑服务通信延迟对服务调用性能的损耗问题，开发人员需要选择合适的通信方式解决这一问题。

在项目中如何选择架构:       

        

虽然微服务有诸多好处，但是不是任何系统都适合用微服务架构来开发，在项目规模不大的情况下单体应用性能表现良好，当项目规模较大，用户体量，并发较大的时候，微服务总体性能占优势，所以我们应该根据项目类型以及项目规模来决定应用架构的选型，如大型电商，物流，售票等系统我们可以选择使用微服务架构，对于中小型的企业级应用我们依然可以选择单体架构。

总结：中小型项目，选择单体 ， 大型项目选择微服务。