微服务架构的理解
Posted zhangxugang
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务架构的理解相关的知识,希望对你有一定的参考价值。
什么是微服务:
相对于系统来说,微服务就是把一个系统按照一定的原则把一个系统拆分为n个服务的,一般按照功能模块进行拆分,如电商系统,一般会拆分为:用户服务,商品服务,订单服务,促销服务等。
微服务解决的问题:
减少了代码冗余,各个微服务都提供了标准的接口,在代码维护上可以把更多的精力放在前端处理上
但是这样的架构没有涉及到数据,那么之后数据库的性能将成为瓶颈
那么在这个阶段可以在做细致一些把数据库进行拆分:用户库,商品库,订单库,促销库等;
这时候我们可以发现商品服务和促销服务访问比较频繁的,那么我们可以在这个位置加入消息队列,用来提高服务的吞吐量,利用redis缓存来提高服务的访问效率
再然后及时可以对数据库,redis和消息队列做高可用处理,即每一个数据库和redis以及消息队列都应该具有不止一个实例
如:对mysql和redis进行以及消息队列,并提供多个节点以保障系统的可用性
在微服务架构形成之后,系统如果一旦出现故障,对故障的排查可能出现困难,而某一个服务的故障可能导致雪崩时的系统奔溃,所以这里需要引入故障预警和故障后的日志处理工具:
如:RedisExporter(Redis系统监控),MysqlExporter(Mysql监控),Prometheus(指标采集器),通过这三个可以把redis和Mysql的运行情况,并对即将出现问题的服务进行及时的预警
除了预警职位还要故障之后的日志查找以及链路跟踪(用户访问造成的所有微服务调用,以及调用关系的记录)
要记录这个关系,需要对用户调用数据进行记录:
一个用户访问应该产生一个访问编号,即traceId
然后,这个访问调用了那个服务,则应该记录该服务的ID,即spanId
这个服务是谁调用的,还应该记录一个父服务的ID,即parentId
然后就是请求时间和相应时间了,requestTime, responseTime
这些参数,应该在调用微服务时加入headers中,这样就可以在微服务中获取到相应的参数,并进行记录了
然后把这些调用相关的数据存入到指定位置待查询
如果一旦出现故障,那么这些调用肯定会出现问题,或则调用缺失,那么问题相对来说就比较容易查找了
这里的几个参数的获取,可以采用微服务代码中实现,也可以采用加一层代理的方式实现(如:Zipkin可以实现http请求拦截器,在拦截后可以加入这些参数)
有了这些基础之后就是对日志进行分析了,可以采用ELK进行分析(Elasticsearch、Logstash和Kibana三个组件的缩写)
- Elasticsearch:搜索引擎,同时也是日志的存储。
- Logstash:日志采集器,它接收日志输入,对日志进行一些预处理,然后输出到Elasticsearch。
- Kibana:UI组件,通过Elasticsearch的API查找数据并展示给用户。
再然后我们要考虑的是,微服务形成之后各种的调用关系错综复杂,且经过一段发展之后各种关系可能错综复杂,且程序员在工作的过程中也完全可能忘记那个位置调用了那个服务
这时候就需要对微服务进行治理
治理微服务需要几个工具:
1.文档
2.调用关系
3.调用网关
这几个即微服务治理系统
文档应该对微服务的接口进行描述,并提供查询功能
调用关系,应该在能够实现动态注册,治理系统中应该能够查到调用关系,和调用记录以及调用结果和调用时间等。
网关的使用上要决定的就是在多大粒度上使用网关,如最粗粒度整个微服务一个网关,外部调用需要通过网关,内部调用不通过网关,相对的最细粒度即,所有调用都通过网关,这种方案是:对微服务进行分区,区内不通过网关,区外通过网关进行调用
在这个上,个人认为粗粒度可能是使用最为广泛的方式。
以上是关于微服务架构的理解的主要内容,如果未能解决你的问题,请参考以下文章