IDEA工具里面使用Maven开发的一个个独立的小Moudle,它具体是使用springboot开发的一个小模块,专业的事情交给专业的模块来做,一个模块就做着一件事情
强调的是一个个的个体,每个个体完成一个具体的任务或者功能!
在当今的软件开发领域中,主要有两种系统架构风格,那就是新兴的“微服务架构”和传统的“单体架构”。
单体架构是微服务架构出现之前业界最经典的软件架构类型,许多早期的项目采用的也都是单体架构。单体架构将应用程序中所有业务逻辑都编写在同一个工程中,最终经过编译、打包,部署在一台服务器上运行。
在项目的初期,单体架构无论是在开发速度还是运维难度上都具有明显的优势。但随着业务复杂度的不断提高,单体架构的许多弊端也逐渐凸显出来,主要体现在以下 3 个方面:
由于单体架构存在这些弊端,因此许多公司和组织都开始将将它们的项目从单体架构向微服务架构转型。对比下微服务架构和单体架构到底有什么不同。
不同点 | 微服务架构 | 单体架构 |
---|---|---|
团队规模 | 微服务架构可以将传统模式下的单个应用拆分为多个独立的服务,每个微服务都可以单独开发、部署和维护。每个服务从设计、开发到维护所需的团队规模小,团队管理成本小。 | 单体架构的应用程序通常需要一个大型团队,围绕一个庞大的应用程序工作,团队管理的成本大。 |
数据存储方式 | 不同的微服务可以使用不同的数据存储方式,例如有的用 Redis,有的使用 MySQL。 | 单一架构的所有模块共享同一个公共数据库,存储方式相对单一。 |
部署方式 | 微服务架构中每个服务都可以独立部署,也可以独立于其他服务进行扩展。如果部署得当,基于微服务的架构可以帮助企业提高应用程序的部署效率。 | 采用单体架构的应用程序的每一次功能更改或 bug 修复都必须对整个应用程序重新进行部署。 |
开发模式 | 在采用微服务架构的应用程序中,不同模块可以使用不同的技术或语言进行开发,开发模式更加灵活。 | 在采用单体架构的应用程序中,所有模块使用的技术和语言必须相同,开发模式受限。 |
故障隔离 | 在微服务架构中,故障被隔离在单个服务中,避免系统的整体崩溃。 | 在单体架构中,当一个组件出现故障时,故障很可能会在进程中蔓延,导致系统全局不可用。 |
项目结构 | 微服务架构将单个应用程序拆分为多个独立的小型服务,每个服务都可以独立的开发、部署和维护,每个服务都能完成一项特定的业务需求。 | 单体架构的应用程序,所有的业务逻辑都集中在同一个工程中。 |
- 遵循单一职责原则设计模式,每个服务足够内聚,足够小,代码容易理解,这样能聚焦一个指定的业务功能或业务需求。按照业务来划分,每个服务通常只专注于某一个特定的业务、所需代码量小,复杂度低、易于维护。
- 每个微服都可以独立开发、部署和运行,且代码量较少,因此启动和运行速度较快,并且从设计、开发、测试到维护所需的团队规模小,一般 8 到 10 人,团队管理成本小。
- 微服务是松耦合的,是有功能意义的服务,无论是在开发阶段或部署阶段都是独立的。
- 在微服务架构中,开发人员可以结合项目业务及团队的特点,合理地选择语言和工具进行开发和部署,不同的微服务可以使用不同的语言和工具。
- 易于和第三方集成,微服务允许容易且灵活的方式集成自动部署,通过持续集成工具,如jenkins,Hudson,bamboo
- 微服务易于被一个开发人员理解,修改和维护,这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
- 微服务允许你利用融合最新技术。
- 微服务只是业务逻辑的代码,不会和HTML,CSS或其他界面混合
- 每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一数据库
- 微服务系统具有链路追踪的能力。
- 微服务能够与容器(Docker)配合使用,实现快速迭代、快速构建、快速部署。
- 采用单体架构的应用程序只要有任何修改,就需要重新部署整个应用才能生效,而微服务则完美地解决了这一问题。在微服架构中,某个微服务修改后,只需要重新部署这个服务即可,而不需要重新部署整个应用程序。
- 微服务具备良好的可扩展性。随着业务的不断增加,微服务的体积和代码量都会急剧膨胀,此时我们可以根据业务将微服务再次进行拆分;除此之外,当用户量和并发量的增加时,我们还可以将微服务集群化部署,从而增加系统的负载能力。
- 微服务具有良好的故障隔离能力,当应用程序中的某个微服发生故障时,该故障会被隔离在当前服务中,而不会波及到其他微服务造成整个系统的瘫痪。
- 开发人员要处理分布式系统的复杂性
- 多服务运维难度,随着服务的增加,运维的压力也在增大
- 系统部署依赖
- 服务间通信成本
- 数据一致性
- 系统集成测试
- 性能监控.
微服务条目 | 落地技术 |
---|---|
服务开发 | SpringBoot,Spring,SpringMVC |
服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 |
服务注册与发现 | Eureka、Consul、Zookeeper等 |
服务调用 | Rest、RPC、gRPC |
服务熔断器 | Hystrix、Envoy等 |
负载均衡 | Ribbon、Nginx等 |
服务接口调用(客户端调用服务的简化工具) | Feign等 |
消息队列 | Kafka、RabbitMQ、ActiveMQ等 |
服务配置中心管理(github远程配置,修改) | SpringCloudConfig、Chef等 |
服务路由(API网关) | Zuu等 |
服务监控 | Zabbix、Nagios、Metrics、Specatator等 |
全链路追踪 | Zipkin、Brave、Dapper等 |
服务部署 | Docker、OpenStack、Kubernetess等(docker还不如k8s,屏蔽了语言特性) |
数据流操作开发包 | SpringCloud Stream(封装与Redis,Rabbit,Kafka等发送接收消息) |
事件消息总线 | SpringCloud Bus |
造成这些问题的原因是:网络是不可靠的,分布式,网络丢包,数据拦截
1.spring cloud netflex 一站式解决方案。我们都可以直接去这里拿(4个问题都可解决)
Springcloud:是一套生态,就是来解决以上分布式架构的4个问题,以http restful风格进行通信的框架。想使用springcloud,必须要掌握SpringBoot,因为SpringCloud是基于SpringBoot;
Api网关,zuul组件
Feign-->Httpclient--->HTTP的通信方式(超文本传输协议,负载均衡),同步并阻塞
服务注册与发现,Eureka
熔断机制,Hystrix
2.Apache Dubbo zookeeper半自动,需要整合别人的!
API Gateway:没有!要么找第三方组件,要么自己实现网关
Dubbo是一个高性能的基于Java实现的RPC通信框架(异步非阻塞)!2.6.x
服务注册与发现,zookeeper(大数据用的多):动物园管理者(Hadoop,Hive)
没有:借助了Hystrix
不完善,专一做rpc通信框架,不和spring cloud竞争
3.SpringCloud Alibaba一站式解决方案!相对netflex简单
Spring Cloud Gateway
Dubbo是一个高性能的基于Java实现的RPc通信框架(异步非阻塞)!2.6.x
Nacos:动态服务发现、配置和服务管理平台
Sentinel: 以流量为切入点,从流量控制、熔断降级、系统负载保护、
Java 微服务框架
市面上的 Java 微服务框架主要有以下 5 种:
- Spring Cloud:它能够基于 REST 服务来构建服务,帮助架构师构建出一套完整的微服务技术生态链。
- Dropwizard:用于开发高性能和 Restful 的 Web 服务,对配置、应用程序指标、日志记录和操作工具都提供了开箱即用的支持。
- Restlet: 该框架遵循 RST 架构风格,可以帮助 Java 开发人员构建微服务。
- Spark:最好的 Java 微服务框架之一,该框架支持通过 Java 8 和 Kotlin 创建微服务架构的应用程序。
- Dubbo:由阿里巴巴开源的分布式服务治理框架。
Go 语言微服务框
Go 语言中的微服务框架较少,使用的较多的是 GoMicro,它是一个 RPC 框架,具有负载均衡、服务发现、同步通信、异步通讯和消息编码等功能。
Phyton 微服务框架
Phyton 中的微服务框架主要有 Flask、Falcon、Bottle、Nameko 和 CherryPy 等。
NodeJS微服务框架
Molecular 是一种使用 NodeJS 构建的事件驱动架构,该框架内置了服务注册表、动态服务发现、负载均衡、容错功能和内置缓存等组件。
为什么选择SpringCloud作为微服务架构?
整体解决方案和框架成熟度
社区热度
可维护性学习曲线:注解
阿里:dubbo+HFS
京东:JSF
新浪:Motan
当当网DubboX
功能点/服务框架 | Netflix/SpringCloud | Motan | gRPC | Thrift | Dubbo/DubboX |
---|---|---|---|---|---|
功能定位 | 整套微服务框架 | RPC框架,整合了ZK或consul实现集群环境的基本服务注册、发现 | RPC框架 | RPC框架 | 服务框架 |
支持rest | 是,Ribbon支持多种可拔插序列号选择 | 否 | 否 | 否 | 否 |
支持RPC | 否 | 是(hession2) | 是 | 是 | 是 |
支持多语言 | 是(rest形式?) | 否 | 是 | 是 | 是 |
负载均衡 | 是(服务端zuul+客户端Ribbon)zuul-服务,动态路由,云端负载均衡Eureka(针对中间服务层) | 是(客户端) | 否 | 否 | 是(客户端) |
配置服务 | Netflix Archaius,Spring Cloud Config Service集中配置 | 是(zookeeper提供) | 否 | 否 | 否 |
服务调用链监控(路由网关) | 是(zuul)zuul提供边缘服务,API网关 | 否 | 否 | 否 | 否 |
高可用、容错 | 是(服务端Hystrix)+客户端Ribbon | 是(客户端) | 否 | 否 | 是(客户端) |
应用案例 | Netflix | Sina | |||
社区活跃度 | 高 | 一般 | 高 | 一般 | 17重新维护,之前中断5年 |
学习难度 | 高 | 低 | 高 | 高 | 低 |
文档丰富 | 高 | 一般 | 一般 | 一般 | 高 |
其他 | SpringCloud Bus给我们的应用程序带来更多管理端点 | 支持降级 | Netflix内部在开发集成gRPC | IDL定义 | 实践公司多 |