标签：分区 标准 实例 冗余 ash 拦截器 决定 参数 过程
什么是微服务：
相对于系统来说，微服务就是把一个系统按照一定的原则把一个系统拆分为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三个组件的缩写）
再然后我们要考虑的是，微服务形成之后各种的调用关系错综复杂，且经过一段发展之后各种关系可能错综复杂，且程序员在工作的过程中也完全可能忘记那个位置调用了那个服务
这时候就需要对微服务进行治理
治理微服务需要几个工具：
1.文档
2.调用关系
3.调用网关
这几个即微服务治理系统
文档应该对微服务的接口进行描述，并提供查询功能
调用关系，应该在能够实现动态注册，治理系统中应该能够查到调用关系，和调用记录以及调用结果和调用时间等。
网关的使用上要决定的就是在多大粒度上使用网关，如最粗粒度整个微服务一个网关，外部调用需要通过网关，内部调用不通过网关，相对的最细粒度即，所有调用都通过网关，这种方案是：对微服务进行分区，区内不通过网关，区外通过网关进行调用
在这个上，个人认为粗粒度可能是使用最为广泛的方式。
标签：分区 标准 实例 冗余 ash 拦截器 决定 参数 过程
原文地址：https://www.cnblogs.com/zhangxugang/p/13084265.html
