docs: improve docs and close doocs#193

Author: yanglbme

docs/high-concurrency/redis-master-slave.md

@@ -82,7 +82,7 @@ client-output-buffer-limit slave 256MB 64MB 60
 
 主从节点互相都会发送 heartbeat 信息。
 
-master 默认每隔 10 秒 发送一次 heartbeat，slave node 每隔 1 秒 发送一个 heartbeat。
+master 默认每隔 10 秒发送一次 heartbeat，slave node 每隔 1 秒发送一个 heartbeat。
 
 ### 异步复制
 

docs/micro-services/huifer-micro-service-governance.md

@@ -1,105 +1,128 @@
 # 微服务治理策略
 
-- Author: [HuiFer](https://github.com/huifer)
-- Description: 该文简单介绍微服务的治理策略以及应用技术
+- Author：[HuiFer](https://github.com/huifer)
+- Description：该文简单介绍微服务的治理策略以及应用技术
 
 ## 服务的注册和发现
 
-> 解决问题: 集中管理服务
+解决问题：集中管理服务
 
-> 解决方法: eureka 、zookeeper
+解决方法：
+
+- Eureka
+- Zookeeper
 
 ## 负载均衡
 
-> 解决问题: 降低服务器硬件压力
+解决问题：降低服务器硬件压力
+
+解决方法：
 
-> 解决方法: nginx 、 Ribbon
+- Nginx
+- Ribbon
 
 ## 通讯
 
-> 解决问题: 各个服务之间的沟通桥梁
+解决问题：各个服务之间的沟通桥梁
+
+解决方法：
 
-> 解决方法 :
->
-> - 同步消息
->
-> 1. rest
-> 1. rpc
->
-> - 异步消息
->
-> 1. MQ
+- REST（同步）
+- RPC（同步）
+- MQ（异步）
 
 ## 配置管理
 
-> 解决问题: 随着服务的增加配置也在增加, 如何管理各个服务的配置
+解决问题：随着服务的增加配置也在增加，如何管理各个服务的配置。
 
-> 解决方法: nacos 、 spring cloud config 、 Apollo
+解决方法：
+
+- Nacos
+- Spring Cloud Config
+- Apollo
 
 ## 容错和服务降级
 
-> 解决问题: 在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可以，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应.
+解决问题：在微服务当中，一个请求经常会涉及到调用几个服务，如果其中某个服务不可以，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。
 
-> 解决方法: hystrix
+解决方法：
 
-## 服务依赖关系
+- Hystrix
 
-> 解决问题: 多个服务之间来回依赖, 启动关系的不明确
+## 服务依赖关系
 
-> 解决方法:
+解决问题：多个服务之间来回依赖，启动关系的不明确。
 
-> 1. 应用分层: 数据层, 业务层 数据层不需要依赖业务层, 业务层依赖数据, 规定上下依赖关系避免循环圈
+解决方法：应用分层。
 
 ## 服务文档
 
-> 解决问题: 降低沟通成本
+解决问题：降低沟通成本
 
-> 解决方法: swagger 、 java doc
+解决方法：
+
+- Swagger
+- Java doc
 
 ## 服务安全问题
 
-> 解决问题: 敏感数据的安全性
+解决问题：敏感数据的安全性
+
+解决方法：
 
-> 解决方法: oauth 、 shiro 、 spring security
+- Oauth
+- Shiro
+- Spring Security
 
 ## 流量控制
 
-> 解决问题: 避免一个服务上的流量过大拖垮整个服务体系
+解决问题：避免一个服务上的流量过大拖垮整个服务体系
+
+解决方法：
 
-> 解决方法: Hystrix
+- Hystrix
 
 ## 自动化测试
 
-> 解决问题: 提前预知异常, 确定服务是否可用
+解决问题：提前预知异常，确定服务是否可用
 
-> 解决方法: junit
+解决方法：
 
-## 服务上线, 下线的流程
+- junit
 
-> 解决问题: 避免服务随意的上线下线
+## 服务上线，下线的流程
 
-> 解决方法: 新服务上线需要经过管理人员审核. 服务下线需要告知各个调用方进行修改, 直到没有调用该服务才可以进行下线.
+解决问题：避免服务随意的上线下线
+
+解决方法：新服务上线需要经过管理人员审核，服务下线需要告知各个调用方进行修改，直到没有调用该服务才可以进行下线。
 
 ## 兼容性
 
-> 解决问题: 服务开发持续进行如何做到兼容
+解决问题：服务开发持续进行如何做到兼容。
 
-> 解决方法: 通过版本号的形式进行管理, 修改完成进行回归测试
+解决方法：通过版本号的形式进行管理，修改完成进行回归测试。
 
 ## 服务编排
 
-> 解决问题: 解决服务依赖问题的一种方式
+解决问题：解决服务依赖问题的一种方式
+
+解决方法：
 
-> 解决方法: docker & k8s
+- Docker
+- K8s
 
 ## 资源调度
 
-> 解决问题: 每个服务的资源占用量不同, 如何分配
+解决问题：每个服务的资源占用量不同，如何分配
+
+解决方法：
 
-> 解决方法: JVM 隔离、classload 隔离 ; 硬件隔离
+- JVM 隔离
+- Classload 隔离
+- 硬件隔离
 
 ## 容量规划
 
-> 解决问题: 随着时间增长, 调用逐步增加, 什么时候追加机器
+解决问题：随着时间增长，调用逐步增加，什么时候追加机器。
 
-> 解决方法: 统计每日调用量和响应时间, 根据机器情况设置阈值, 超过阈值就可以追加机器
+解决方法：统计每日调用量和响应时间，根据机器情况设置阈值，超过阈值就可以追加机器。