Fix multiple typos in shumei.md (#1159)

content/zh/cooperation/shumei.md

@@ -73,7 +73,7 @@ Kitex 文档提供了很多参数设置和参考意见，同时我会提供一
 
 我们公司是一个典型的三层微服务业务架构：**接入层-逻辑业务层-基础服务层**。
 
-我们基础服务，接入层通过 HTTP 请求接入用户的请求，内部服务使用 thrift 协议做 RPC ，进行微服务间的调用。业务层处理大部分业务逻辑，基础服务大部分是线上的机器学习预测服务，几乎都是计算密集型的服务，大部分都是 GPU 的预测服务，然后我们大概线上有数百个不同的类型的服务，以及线上数百个不同类型的服务，大概几千个实例，每天要承受接近 30 亿多的日请求量。
+我们基础服务，接入层通过 HTTP 请求接入用户的请求，内部服务使用 thrift 协议做 RPC ，进行微服务间的调用。业务层处理大部分业务逻辑，基础服务大部分是线上的机器学习预测服务，几乎都是计算密集型的服务，大部分都是 GPU 的预测服务，然后我们大概线上有数百个不同的类型的服务，大概几千个实例，每天要承受接近 30 亿多的日请求量。
 
 我们公司是 15 年左右成立的，一般认为，一个公司的基础架构需要 5 年进行一次更新。我们公司刚好需要进行下一次基础设施相关的更新，因为我们的基础服务架构缺少很多现在主流的治理特性。在高并发的情况下，暴露出了许多稳定性问题。因此，我们亟需一个高性能、集成多种治理特性解决稳定性问题、方便定制可以融入当前基础设施。因此，我们通过一些调研，选择了 Kitex 作为服务框架。
 
@@ -311,7 +311,7 @@ Adaptive LIFO
 
 - **做好客户** **QPS** **的限制和集群预留足够的冗余。** 对于具有多租户的 SaaS 系统，一定要做好客户 QPS 的限制，因为资源是有限的，不可能给每个客户都预留足够多的 QPS 这种限额，因为实在是太贵了。此外，要预留足够的冗余，但是在平衡成本时，需要相对精确地预测客户的流量。
 - **请求处理速率跟不上请求到达速率，尽早丢弃请求。** 在整个微服务架构下，处理请求的哲学。
-- **选择合适的熔断** **、过载保护策略。** Kitex 提供了很好的熔断过载保护的机制，用户可以选择自己熔断或过载保护的策略。流量是检查效果的唯一标准。经过足够多流量验证的 categ 真是非常好的选择，因为像熔断、国宅保护等这些机制，有很多边界 case，需要将这些边界 case 都通过自己的流量去验证。
+- **选择合适的熔断** **、过载保护策略。** Kitex 提供了很好的熔断过载保护的机制，用户可以选择自己熔断或过载保护的策略。流量是检查效果的唯一标准。经过足够多流量验证的 categ 真是非常好的选择，因为像熔断、过载保护等这些机制，有很多边界 case，需要将这些边界 case 都通过自己的流量去验证。
 - **流量是检验效果的唯一标准，经过足够多流量验证的** **Kitex** **是很好的选择。** 在字节跳动，经过了足够多的验证，很多边界 case 已经解决了，所以我们选择 Kitex 开源框架一定是非常好的选择。
 
 > Kitex Github：https://github.com/cloudwego/kitex