标签：调用 服务 注册 SpringCloud 单体 学习 应用 组件 架构
微服务架构与单体应用区分
-
单体应用的特点:
-
所有的系统模块都在同一个应用内
-
对外提供的接口是统一的
-
-
单体项目存在的问题：
-
一个成功的应用都有一个趋势，他会随着时间的推移结构会变的越来越臃肿
-
当单体项目结构变得越来越庞大、复杂之后使用项目的扩展和更新都变得越来越困难
-
随着单体应用规模越来越大启动时间也会越来越长，生产力就会非常大的限制
-
复杂的单体项目本身就是持续部署的障碍(尤其是想要更新项目中任何一个模块，就得重新部署整个应用程序)
-
单体应用中任何一个模块的bug都可能拖垮整个应用
-
单体项目使得采用新框架和新技术都会变得非常困难
-
当不同模块存在资源冲突时，单体应用很难扩展
-
-
微服务结构
-
概念
微服务是一种架构概念，能够将应用中的功能分解到各个离散的服务，能够实现解耦，并提供了更加灵活的服务支持
-
优点
-
解决单体项目的复杂性问题
-
每个服务都可以由独立的团队开发
-
每个服务都可以用独立的技术栈
-
每个服务都可以独立的进行部署
-
每个服务都可以独立的进行拓展
-
-
缺点
-
微服务结构本身就是一个缺点，微服务这个词重点过多的偏向于服务规模，但是微服务本身的主要目标在于充分的分解应用以便于应用的开发与部署
-
微服务架构是一个分布式系统，虽然单个服务变得简单了，但是整个系统却变得更繁杂了
-
使用微服务架构还得依赖分布式数据库
-
测试微服务应用程序会变得相对麻烦
-
部署基于微服务架构的应用程序也是比较复杂的
-
这么多服务如何互相发现呢?
-
通过服务注册与发现中心完成服务之间的注册与发现
-
服务提供者在服务注册与发现中心进行注册
-
服务注册与发现中心记录服务提供者的信息(服务名和ip),并于服务提供者保持心跳
-
服务消费者在服务注册与发现中心进行服务查询，服务注册与发现中心返回服务地址列表
-
服务消费者负载均衡访问服务提供者
-
-
-
服务之间如何进行通信?
每个服务都是一个独立的应用，完成独立的功能，如果服务之间需要相互依赖和调用，首先是通过服务注册于发现中心查询，查询完毕之后实现服务之间的通信
服务之间的通信方式有两种:同步调用和异步消息调用
-
同步调用：
-
Rest(Springcloud)
-
基于HTTP协议
-
更容易实现，技术更灵活
-
支持多语言，同时实现客户端操作
-
适用面比较广(只要能实现HTTP协议)
-
-
RPC(Dubbo)
-
传输效率更高
-
更安全可控
-
如果有统一的开发规范及统一的服务框架时，开发效率更好
-
-
-
异步消息调用：
-
消息队列
-
-
-
服务挂了，如何解决？
-
服务集群&负载均衡----->尽量保证服务可用
-
熔断器机制&服务降级处理---->保证用户正常响应
-
-
客户端如何访问不同的服务呢? Zuul
-
-
-
SpringCloud核心组件
-
Eureka:服务治理组件、服务注册与发现
-
Ribbon:服务访问组件，服务的调用
-
Feign:服务访问组件(基于Ribbon的封装实现)，服务的调用
-
HyStrix:服务容错管理(服务降级、服务熔断)组件
-
zuul:网关组件
标签：调用,服务,注册,SpringCloud,单体,学习,应用,组件,架构
来源： https://www.cnblogs.com/clematis/p/16272586.html
本站声明：
1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。