1. 单体架构的问题
在Java Web开发中,web工程一般会被打包为war包部署在Servlet容器中,如Tomcat。比较简单,开发和调试部署都很方便。
但是当用户量大时,并发量高时,一台机器是无法满足系统的负载的,我们会考虑水平拓展,比如增加服务器的数量,通过负载均衡器(如Nginx)很容易实现应用的水平拓展。但是时间推移,还是会产生很多问题:
应用复杂度增加,更新、维护困难
影响开发效率
应用可靠性降低,这么大一个应用比如出现一个Bug,整个崩溃。
2. SOA
针对传统的单体架构问题。大部分企业通过SOA(Service-Oriented Architecture,面向服务的架构)来解决。SOA的思路是把应用中相近的功能聚合到一起,以服务的形式提供出去,可以理解为一批服务的组合。
SOA将原来的单体架构按照功能细分为不同的子系统,然后再由各个子系统依赖服务中间件来调用所需服务。
使用SOA将系统切分为多个组件服务,这种通过多个组件服务来完成请求的方式有很多好处,比如不同团队的可以负责不同的子项目;模块拆分,使用通讯接口,降低了模块之间的耦合度等等。
SOA架构和微服务架构的区别
首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。
1).SOA(Service Oriented Architecture)“面向服务的架构”:他是一种设计方法,其中包含多个服务, 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
2).微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华,微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
3. 微服务架构
微服务架构是一种架构风格和架构思想,它倡导文明在传统软件应用架构的基础上,将系统业务按照功能拆分为更加细粒度的服务,所拆分的每一个服务都是一个独立的应用,这些应用对外提供公共的API(一般使用REST API),可以独立承担对外服务的职责。
特点:
根据业务模块化分服务种类
每个服务可独立部署且相互隔离
通过轻量级API调用服务
服务虚保证良好的高可用性(HA:比如使用集群,避免单一节点死掉无法继续服务)
3.1 微服务架构和SOA区别
其实主要也是粒度的区别,对SOA不熟,不过听老师说SOA现在的都是那些老应用了,有点过时了
3.2 微服务架构的组件
服务注册中心(Service Registry):注册系统所有服务的地方。
服务注册:服务提供方(比如订单服务)将自己的地址注册到服务注册中心,让服务调用方能够方便地找到自己。
服务发现:服务调用方(客户端)从服务注册中心找到自己需要调用服务的地址。
服务网关(API Gateway):也称为API网关,是服务调用的唯一入口(用户访问从这里进),可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。
负载均衡:服务提供方一般以多实例的形式提供服务,使用负载均衡能够让服务调用方法接到合适的节点(每个服务都是一个项目,比如我把那个订单服务做Nginx反向代理负载均衡,这里没有画上去)
服务容错:通过断路器(也称断容器)等一系列的服务保护机制,保护服务调用者在调用异常服务时能快速地返回结果,避免大量的同步等待。(这个在API Gateway到每个微服务的连接中设置)
分布式配置中心:将本地化的配置信息(properties、yml、yaml等) 注册到配置中心,实现程序包在开发、测试、生产环境的无差别性,方便程序包的迁移。
等等组件(以上基本够用)…
部署运行过程:
部署了一系列的微服务,每个微服务都会访问自己的数据库。这些微服务启动时,会将其信息注册到服务注册中心,在客户端发送请求时,请求首先被API网关拦截,API网关会读取请求数据,并从注册中心获取对应的服务信息,然后API网关会更具服务信息调研所需的微服务。
3.3 微服务的技术选型
微服务实例的开发:常用Spring Boot
服务的注册与发现:Spring Cloud Eureka、Apache Zookeeper、Dubbo
负载均衡:Spring Cloud Ribbon、Dubbo
服务容错:Spring Cloud Hystrix
API网关:Spring Cloud Zuul、Spring Reactor、Nettry或者NodeJS
分布式配置中心:Spring Cloud Config
调试:swagger
部署:Jenkins+Docker
比如下面这种: