Merge pull request servicemesher#31 from godliness/fix-3.2

Fix some sentence mistakes

concepts-and-principle/what-is-service-mesh.md

@@ -37,7 +37,7 @@ Service mesh 又译作 “服务网格”，作为服务间通信的基础设施
 2. 网络层的出现
 3. 集成到应用程序内部的控制流
 4. 分解到应用程序外部的控制流
-5. 应用程序的中集成服务发现和断路器
+5. 应用程序中集成服务发现和断路器
 6. 出现了专门用于服务发现和断路器的软件包/库，如 [Twitter 的 Finagle](https://finagle.github.io/) 和 [Facebook  的 Proxygen](https://code.fb.com/networking-traffic/introducing-proxygen-facebook-s-c-http-framework/)，这时候还是集成在应用程序内部
 7. 出现了专门用于服务发现和断路器的开源软件，如 [Netflix OSS](http://netflix.github.io/)、Airbnb 的 [synapse](https://github.com/airbnb/synapse) 和 [nerve](https://github.com/airbnb/nerve)
 8. 最后作为微服务的中间层服务网格出现
@@ -59,8 +59,8 @@ Service mesh 又译作 “服务网格”，作为服务间通信的基础设施
 3. Istio 根据它观测到最近请求的延迟时间，选择出所有应用程序的实例中响应最快的实例。
 4. Istio 将请求发送给该实例，同时记录响应类型和延迟数据。
 5. 如果该实例挂了、不响应了或者进程不工作了，Istio 将把请求发送到其他实例上重试。
-6. 如果该实例持续返回 error，Istio 会将该实例从负载均衡池中移除，稍后再周期性得重试。
-7. 如果请求的截止时间已过，Istio 主动失败该请求，而不是再次尝试添加负载。
+6. 如果该实例持续返回 error，Istio 会将该实例从负载均衡池中移除，稍后再周期性的重试。
+7. 如果请求的截止时间已过，Istio 主动以失败的方式结束该请求，而不是再次尝试添加负载。
 8. Istio 以 metric 和分布式追踪的形式捕获上述行为的各个方面，这些追踪信息将发送到集中 metric 系统。
 
 ## 为何使用服务网格？
@@ -69,7 +69,7 @@ Service mesh 又译作 “服务网格”，作为服务间通信的基础设施
 
 在传统的 MVC 三层 Web 应用程序架构下，服务之间的通讯并不复杂，在应用程序内部自己管理即可，但是在现今的复杂的大型网站情况下，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂，出现了 twitter 开发的 [Finagle](https://twitter.github.io/finagle/)、Netflix 开发的 [Hystrix](https://github.com/Netflix/Hystrix) 和 Google 的 Stubby 这样的 “胖客户端” 库，这些就是早期的服务网格，但是它们都仅适用于特定的环境和特定的开发语言，并不能作为平台级的服务网格支持。
 
-在云原生架构下，容器的使用给予了异构应用程序的更多可行性，Kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。
+在云原生架构下，容器的使用给予了异构应用程序的更多可行性，Kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过多关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。
 
 ## 参考