架构知识——分布式、集群、SOA、微服务

架构演变

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
架构演变从 单一架构->垂直架构->分布式架构->SOA架构->微服务架构

1.单一架构

• 当网站流量很小时，只需一个应用，将所有功能放在一个工程（比如商城有用户管理、商品管理、后台管理、订单管理等），生成一个war包，将这个war包放到web容器中（比如tomcat），以减少部署节点和成本。
• 优点：开发简单，适用于小型应用。
• 缺点：不易扩展和维护，代码耦合度较高。某个功能出现问题，导致整个工程都不能访问。
  

2.垂直架构

• 针对单一架构中存在的缺点，把一个项目拆分成若干个子项目（按照单一应用架构中的不同功能拆分），比如将一个商城拆分成用户中心系统、商品系统、后台系统、订单管理系统等，每个子系统就是一个子工程，每个war包独立运行在一个web容器中。用户在访问系统时，都是直接访问的各个系统，比如用户中心系统访问人数过多，只要对该系统进行集群部署。
• 优点：解决高并发问题；可以针对不同的模块进行优化；方便水平扩展和容错。
• 缺点：系统之间有太过于独立，子系统之间无法相互调用（比如用户中心想要调用商品系统，不知如何调用）；每个模块会有重复性的开发工作（比如商品系统和后台系统都有关于商品信息维护的代码）
  

集群概念

同一个工程部署到多台服务器上。每个服务器运行的都是同一个功能，做的同一件事。集群中会使用nginx来实现负载均衡

伪集群概念

• 所有集群的节点搭在一台机器上（192.168.25.138），通过IP下不同的端口号来实现访问，那种就是比较经常听到的“伪集群”
• 所有集群的节点分布在多台机器上就是“真集群”，每个节点所在的IP地址是不一样的
• 如果只是为了分散web应用容器的并发去做的集群，那么可以选用伪集群，如果要保证节点可用性的情况下，建议还是用真集群

3.分布式架构

• 针对分布式架构中存在的缺点，当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。展示层/功能层作为前端调用服务层。
• 优点：将垂直应用中的基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率。
• 缺点：随着业务的不断增多，服务的评估、治理和调度问题需要解决。
  
  

分布式+集群

先分布式，把大的工程拆分成一个个独立的子系统，各个子系统之间通过dubbo来通信（这个dubbo也可以设立集群、nginx），然后每个独立的子系统建立真集群，用nginx来实现集群的负载均衡

分布式系统之间的通信方式

由于分布式是把系统按照模块拆分成多个子系统，那么问题来了，独立工程或者系统之间如何实现通信呢？

• Webservice：效率不高，基于soap协议，在项目中一般不推荐使用。一般跨语言、跨平台会用，两个公司之间存在调用关系会用，比如A公司使用java开发，要调用B公司的PHP项目
• 使用restful形式的服务：http+json。restful是一种风格，本质是一个get请求，就可以传json数据，json比xml更加简洁、传输速率快、解析速率要快，很多项目中应用。使用http必须知道服务的ip和端口，但如果服务太多，服务之间调用关系混乱，需要治理服务
• 使用dubbo。dubbo不能跨语言，只能是java，使用rpc协议进行远程调用，直接使用socket通信(socket传的是二进制，不是传的xml，也不是json，而是java对象，因此效率比http高)。传输效率高，并且可以统计出系统之间的调用关系、调用次数

4.分布式SOA架构

针对分布式架构中存在的缺点，提出SOA(Service Oriented Architecture)，即面向服务的架构。在分布式的基础上将系统分为表现层和服务层，一个表现层可以调用多个服务。而对于服务层中的一个个服务，就是在垂直应用的基础上抽取了一些最底层的应用或者最底层的基础服务，构建出了一个个独立的服务。表现层/功能层就是通过ESB或者dubbo对服务层进行调用，ESB和dubbo就是对下面的服务层调用进行管理，包括服务编排、调度和负载均衡等。

• 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率，此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键
• esb(企业服务总线)和dubbo这两种框架都实现了SOA，是资源调度和治理中心的管理工具
• 优点：抽取公共的功能为服务，提高开发效率；对不同的服务进行集群化部署解决系统压力；基于ESB和dubbo减少系统耦合，只是减少了，但耦合还是存在的
• 缺点：抽取服务的粒度较大（比如说用户服务中全是和用户相关的，包含用户账户和用户详情，全部都在一个里面，做不到更加细化的拆分）；服务提供方与调用方接口耦合度较高
  
  

5.微服务

• 针对SOA架构中存在缺点进行改进，提出微服务概念，微服务是在SOA基础上的升华。微服务强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统拆分成多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务完成交互和集成。做到对服务进行原子化拆分，尽可能拆分，拆到不能拆分为止，然后对各个微服务独立打包运行。
• 表现层和服务层通过轻量级的调用协议进行解耦，不用再去借助复杂的调用技术，只需要发送一个基于http的请求，表现层和服务层之间没有紧密的必然关系，这样就进行了两端之间的解耦。一个服务只提供单一的职责，只做一件事，拆分的粒度比较小，每个服务都需要对外提供http接口供前端调用。
• 优点：通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅下降；微服务遵循单一原则，微服务之间采用Resetful等轻量级协议传输。
• 缺点：微服务过多，服务治理成本高，不利于系统维护（比如在SOA架构中，服务层只有3个，用户服务、订单服务和其他服务，只需要提供三个独立应用，但是微服务中可能有10多个独立应用）；分布式系统开发的技术成本高。