SpringBoot-19-聊聊现在和未来

1. 回顾以前

三层架构-》MVC
	架构 --- 》 解耦

开发框架
	Spring:是一个轻量级的Java开源框架，容器
		IOC ：控制反转
			原来都是自己一步步操作，现在交给容器，需要什么就去拿就行
		AOP ：面向切面编程
			本质：动态代理
			为了解决不影响业务本来情况下，实现动态增加功能，大量应用在日志，事务等等方面
	SpringBoot : 新一代JavaEE开发标准
		并不是新东西，就是Spring的升级版
		开箱即用，自动装配
		特性：约定大于配置


随着公司体系越来越大，用户越来越多！

微服务架构====》新架构
	模块化，功能化！
	一台服务器解决不了，再增加服务器！ （横向）
	
	将原来整体项目模块化
	
	用户非常多的情况下，而其他特别少（给用户多一点服务器）
	将原来整体的项目，分成模块化，用户需要的就是一个单独的项目，并且项目和项目之间需要通信

微服务架构的问题？
	分布式架构会遇到四个核心问题？
	1. 这么多服务，客户端该如何去访问？
	2. 这么多服务，服务之间如何进行通信？
	3. 这么多服务，该如何治理？
	4. 服务挂了，怎么办？

解决方案：
	SpringCloud:是一套生态（就是来解决以上分布式架构的4个问题）基于SpringBoot
	
	1. Spring Cloud Netflix(一站式解决方案：直接去这里拿)
		Api网关，zuul组件
		Feign  -->基于HttpClient-->基于Http的通信方式（同步并阻塞）
		服务注册与发现：Eureka
		熔断机制：Hystrix
	2018年底,NetFlix生态不再维护
	
	2. Apache Dubbo zookeeper:第二套解决系统
		Api网关：没有，要自己实现
		Dubbo: RPC通信框架，高性能Java框架
		服务注册与发现：zookeeper(Hadoop,Hive)
		熔断机制：没有 借助了Hystrix
	
	3.Spring cloud Alibaba （一站式解决方案）

2. 展望未来

目前又提出一种解决方案：
	服务网格：下一代微服务标准（Server mesh）
	代表解决方案：istio(未来可能掌握)
	
以上所有解决的本质问题
	1. API 网关，服务路由
	2. Http,RPC框架，异步调用
	3. 服务注册和发现，高可用
	4. 熔断机制：服务降级
	
	
为什么要解决这些问题？
	本质：网络不可靠！！

3. SOA和微服务

首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。

1.****S*OA（Service Oriented Architecture）“面向服务的架构”:*他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

2.微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

3.1 ESB和微服务API网关

1.ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通；

2.API网关 ： API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。**API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。**通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务

3.2 区别总结

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	总是松耦合
公司架构	任何类型	小型、专注于功能交叉团队
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	执行新功能、快速拓展开发团队

打赏