微服务技术栈(概括)

这边文章粗略结合图片宏观概括下微服务技术栈。
在这里插入图片描述

一、微服务框架

1、服务集群
  单体项目拆分成独立项目(服务,每个服务完成一部分的业务功能)形成服务集群。一个业务往往需要多个服务去完成。

2、注册中心
  越多的和越复杂的业务越来越多会使服务之间的调用关系非常复杂,人工无法完成,注册中心就是用于记录每个服务的IP、端口、什么作用这些信息,当一个服务需要调用其他服务时,只需要从注册中心拉取对应的服务信息即可,无需自己记录。

3、配置中心
  服务越来越多,每个服务都会有很多配置信息,配置中心可以做到统一管理集群中的所有配置。若有配置变更,找到配置中心,它会通知相关的服务实现配置的“热更新”。

4、服务网关
  一方面对用户身份做校验,将用户请求路由到具体的微服务,也可以做一些负债均衡。

5、数据库
  数据库也可能是集群,但仍可能无法抗住并发,需要引入缓存。主要职责就是做一些写操作或者事务类型的对数据安全要求较高的数据存储。

6、分布式缓存
  缓存就是将数据存在内存中,数据库则是存在磁盘上,优劣可见。应对高并发需要将缓存做成分布式缓存。用户请求先到缓存,缓存未命中再访问数据库。
  
7、分布式搜索
  海量数据的搜索,统计和分析可以用分布式搜索完成,简单的查询可以走缓存。
  
8、消息队列
  正常情况一个业务可能需要走多个服务,A-B-C-D,由A调用B,B调用C,C调用D,时间就是这几个服务调用的时间之和,往往实际业务可能更复杂,这样长链路调用会对性能造成影响,于是引进了消息队列。调用A后,A发一个消息给BCD,让BCD开始工作,A则是结束就直接关掉了,链路变短以及吞吐能力加强,做到异步通信的效果,从而提高效率。

10、分布式日志服务
  庞大复杂的系统不易排查定位问题,需引入分布式日志服务,方便分体追踪排查。
  
9、系统监控链路追踪
  实时监控集群中每个服务节点的运行状态,cup负载以及内存的占用等等情况,一旦出现任何问题可以直接定位到异常信息。

二、持续集成

庞大的系统手动部署不合实际,需进行持续集成。
1、Jenkins
  自动化编译

2、docker
  打包镜像

3、kubernetes/RANCHER
  实现自动化部署

各组件实际介绍会在其他的文章中进行介绍。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值