我对微服务框架的理解

最近一直在学习现在最火的微服务，记录一下我对微服务框架的理解吧。

1 单体项目的缺点

之前我们写的项目多为单体项目，所有的功能都集中在一个运行的程序的项目,称为单体项目.
根据我之前写的一个项目画个关系图解释一下

随着功能的添加,单体项目中的业务逻辑变得越来越复杂

单体项目的缺点如下
并发集中
由于所有的访问功能,都集中在一个应用,导致"木桶原理",某一个功能并发过高时达到了系统的上限,其他功能都不能访问了(平时应用过程不会出现的)

单体项目结构中,这个并发集中的问题无法解决.

功能强耦合
系统的功能特别复杂的时候,业务逻辑是很大的开发学习 成本.尽可能的让不同的开发人员掌握不同的业务领域.对于分布式开发结构,对于团队的管理,对于系统的构建都是有非常大的好处的.

单体项目一定存在功能强耦合的,体现在某一个领域的功能要结合另外几个领域的功能一并开发.

所以我们得出结论:
如果单体项目功能并不复杂,公司管理成本不需要考虑,就使用单体项目开发.

一旦需要考虑上述问题,不能再使用单体项目作为应用开发结构,要对项目进行拆分. 可以通过对单体项目的业务功能拆分,实现解耦的操作

2.项目的拆分

横向拆分
横向拆分不能解决单体项目的问题,仅仅是分布式并行开发的方式.

横向拆分: 利用maven这种项目管理工具的依赖特点(依赖可以传递,别人开发的代码,可以被其他人依赖使用). 可以根据项目的不同分层(控制层,业务层,持久层,其他代码)交给不同人员开发,最终运行的还是一个单体项目,只不过是通过相互依赖,将一个项目的完整代码拆分给多个人开发.

纵向拆分
纵向拆分:根据不同的业务功能(电商的业务功能:用户系统,商品系统,购物车系统,订单系统…),将每个功能都独立运行(每个功能都包含了三层开发结构)

开发这样结构的系统,就不是单体系统了,并发集中,功能强耦合的问题不存在了

并发集中:

无论支付系统的上限多高多低,达到上限也不会造成与积分逻辑相关的访问被拒绝

功能强耦合:

开发人员可以专线考虑支付的逻辑.或者积分的逻辑,不需要考虑额外的内容.

3.拆分后项目问题

功能调用
order-user系统为例.如果实现纵向拆分,按照业务功能拆分,定义与订单支付有关的功能(订单支付)独立运行到一个系统,与用户积分有关的功能(积分查询,积分更新)独立运行到一个系统.支付过程应该完成支付打印,和积分新增调用.考虑如何使用系统代码调用其他功能.

每一个独立运行的系统,都要支持被别人负载均衡的调用

如果在这里使用nginx负载均衡http服务器代理,将会造成业务功能(拆分的系统)越多,越复杂,upstream配置就越多.在一个不稳定的网络环境中,服务器宕机,网络延迟都会导致,人为的需要大量修改这些静态配置.

结论:一定需要负载均衡调用,对于每一个独立运行的功能,又不能使用ngixn这种负载均衡静态配置实现大量集群的配置内容.

内部调用外部调用
当拆分一个负载的系统,行程非常多的独立运行的系统,会造成调用出现不同的层次,有外部直接调用(浏览器,js,ajax,其他公司系统),也有内部调用(自己拆分的系统之间的相互调用)

3.3调用失败
拆分的多个系统之间负载均衡调用,由于某个被调用的工程在运行时由故障,网络波动导致本次调用失败如何处理容错的问题.在庞大的拆分结构中,不允许大量的频繁的出现访问拒绝延迟.

4 微服务

微服务
单体项目有并发集中,功能强耦合,所以需要项目纵向拆分,单独运行工程只管理一部分业务逻辑,相互之间有可能存在调用关系.功能越复杂的系统,考虑的问题就越多,需要因为微服务概念解决

微服务: 通过对一个单体项目的纵向拆分得到的拆分结果中,每一个独立运行的系统都是微服务

微:不代表小,一个微服务存在的功能非常复杂,相对于拆分之前的单体项目变得小了
服务:体现在被调用的逻辑
5.2微服务框架和解决方案
微服务的概念出现后,出现了非常多个系统转化为微服务结构,必定经过项目拆分,出现前面提到的一些问题,需要引入微服务框架技术,实现问题的处理.springcloud+springboot+其他技术(mysql redis rabbitmq)其中一种解决方案

springboot+dubbo(springcloud类似的一种微服务框架)

springboot+springcloud alibaba(spring整合了alibaba的微服务技术一个新框架)

springcloud概括
轻量级的spring社区维护的微服务框架.有多个不同的组件组成(并不是一个框架技术的学习).应用非常简单,spring将一些成熟的组件不断的更新到springcloud框架中,使得开发微服务结构时候,不需要考虑太多的延伸的自定义的代码内容.配合springboot框架可以实现简单配置,快速的发布运行.