架构知识——分布式、集、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多个独⽴应⽤）；分布式系统开发的技术成本⾼。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。