fix misspelling and improve README (#208)

Signed-off-by: Sad-polar-bear <[email protected]>

README.md

@@ -29,17 +29,17 @@
 
 **Aeraki** [Air-rah-ki] is the Greek word for 'breeze'. While service mesh becomes an important infrastructure for microservices, many(if not all) service mesh implementations mainly focus on HTTP protocols and treat other protocols as plain TCP traffic. Aeraki Mesh is created to provide a non-intrusive, highly extendable way to manage any layer-7 traffic in a service mesh. 
 
-Note: Aeraki only handles none-HTTP layer-7 traffic in a service mesh, and leaves the HTTP traffic to other existing service mesh projects. (As they have already done a very good job on it, and we don't want to reinvent the wheel! ) 
+Note: Aeraki only handles non-HTTP layer-7 traffic in a service mesh, and leaves the HTTP traffic to other existing service mesh projects. (As they have already done a very good job on it, and we don't want to reinvent the wheel! ) 
 Aeraki currently can be integrated with Istio, and it may support other service mesh projects in the future.
 
 ## Problems to solve
 
 We are facing some challenges in service meshes:
-* Istio and other popular service mesh implementations have very limited support for layer 7 protocols other than HTTP and gRPC.
+* Istio and other popular service mesh implementations have very limited support for layer-7 protocols other than HTTP and gRPC.
 * Envoy RDS(Route Discovery Service) is solely designed for HTTP. Other protocols such as Dubbo and Thrift can only use listener in-line routes for traffic management, which breaks existing connections when routes change.
 * It takes a lot of effort to introduce a proprietary protocol into a service mesh. You’ll need to write an Envoy filter to handle the traffic in the data plane, and a control plane to manage those Envoy proxies.
 
-Those obstacles make it very hard, if not impossible, for users to manage the traffic of other widely-used layer 7 protocols in microservices. For example, in a microservices application, we may have the below protocols:
+Those obstacles make it very hard, if not impossible, for users to manage the traffic of other widely-used layer-7 protocols in microservices. For example, in a microservices application, we may have the below protocols:
 
 * RPC: HTTP, gRPC, Thrift, Dubbo, Proprietary RPC Protocol …
 * Messaging: Kafka, RabbitMQ …
@@ -52,17 +52,17 @@ If you have already invested a lot of effort in migrating to a service mesh, of
 
 ## Aeraki's approach
 
-To address these problems, Aeraki Mesh providing a non-intrusive, extendable way to manage any layer 7 traffic in a service mesh.
+To address these problems, Aeraki Mesh provides a non-intrusive, extendable way to manage any layer-7 traffic in a service mesh.
 ![ Aeraki ](docs/aeraki-architecture.png)
 
 As this diagram shows, Aeraki Mesh consists of the following components:
 
 * Aeraki: [Aeraki](https://github.com/aeraki-mesh/aeraki) provides high-level, user-friendly traffic management rules to operations, translates the rules to envoy filter configurations, and leverages Istio’s `EnvoyFilter` API to push the configurations to the sidecar proxies. Aeraki also serves as the RDS server for MetaProtocol proxies in the data plane. Contrary to Envoy RDS, which focuses on HTTP, Aeraki RDS is aimed to provide a general dynamic route capability for all layer-7 protocols.
-* MetaProtocol Proxy: [MetaProtocol Proxy](https://github.com/aeraki-mesh/meta-protocol-proxy) provides common capabilities for Layer-7 protocols, such as load balancing, circuit breaker, routing, rate limiting, fault injection, and auth. Layer-7 protocols can be built on top of MetaProtocol. To add a new protocol into the service mesh, the only thing you need to do is implementing the [codec interface](https://github.com/aeraki-mesh/meta-protocol-proxy/blob/ac788327239bd794e745ce18b382da858ddf3355/src/meta_protocol_proxy/codec/codec.h#L118) and a couple of lines of configuration. If you have special requirements which can’t be accommodated by the built-in capabilities, MetaProtocol Proxy also has an application-level filter chain mechanism, allowing users to write their own layer-7 filters to add custom logic into MetaProtocol Proxy.
+* MetaProtocol Proxy: [MetaProtocol Proxy](https://github.com/aeraki-mesh/meta-protocol-proxy) provides common capabilities for Layer-7 protocols, such as load balancing, circuit breaker, routing, rate limiting, fault injection, and auth. Layer-7 protocols can be built on top of MetaProtocol. To add a new protocol into the service mesh, the only thing you need to do is to implement the [codec interface](https://github.com/aeraki-mesh/meta-protocol-proxy/blob/ac788327239bd794e745ce18b382da858ddf3355/src/meta_protocol_proxy/codec/codec.h#L118) and a couple of lines of configuration. If you have special requirements which can’t be accommodated by the built-in capabilities, MetaProtocol Proxy also has an application-level filter chain mechanism, allowing users to write their own layer-7 filters to add custom logic into MetaProtocol Proxy.
 
 [Dubbo](https://github.com/aeraki-mesh/meta-protocol-proxy/tree/master/src/application_protocols/dubbo) and [Thrift](https://github.com/aeraki-mesh/meta-protocol-proxy/tree/master/src/application_protocols/thrift) have already been implemented based on MetaProtocol. More protocols are on the way. If you're using a close-source, proprietary protocol, you can also manage it in your service mesh simply by writing a MetaProtocol codec for it.
 
-Most request/response style, stateless protocols can be built on top of the MetaProtocol Proxy. However, some protocols' routing policies are too "special" to be normalized in MetaProtocol. For example, Redis proxy uses a slot number to map a client query to a specific Redis server node, and the slot number is computed by the key in the request. Aeraki can still manage those protocols as long as there's an available Envoy Filter in the Envoy proxy side. Currently, for protocols in this category, [Redis](https://github.com/aeraki-mesh/aeraki/blob/master/docs/zh/redis.md) and Kafka are supported in Aeraki.
+Most request/response style, stateless protocols can be built on top of the MetaProtocol Proxy. However, some protocols' routing policies are too "special" to be normalized in MetaProtocol. For example, the Redis proxy uses a slot number to map a client query to a specific Redis server node, and the slot number is computed by the key in the request. Aeraki can still manage those protocols as long as there's an available Envoy Filter in the Envoy proxy side. Currently, for protocols in this category, [Redis](https://github.com/aeraki-mesh/aeraki/blob/master/docs/zh/redis.md) and Kafka are supported in Aeraki.
 ## Reference
 * [Implement an application protocol](https://www.aeraki.net/zh/docs/v1.0/tutorials/implement-a-custom-protocol/)
 * [Dubbo (中文) ](https://github.com/aeraki-mesh/dubbo2istio#readme)
@@ -75,22 +75,22 @@ Aeraki can manage the below protocols in a service mesh：
 * Kafka (Envoy native filter)
 * Redis (Envoy native filter)
 * MetaProtocol-Dubbo
-* MetaProtocol-Thfirt
+* MetaProtocol-Thrift
 * MetaProtocol-bRPC (A RPC protocol open-source by Baidu)
 * MetaProtocol-tRPC (A proprietary RPC protocol used in Tencent）
 * MetaProtocol-qza (A proprietary protocol used in Tencent Music)
 * MetaProtocol-videoPacket (A proprietary protocol used in Tencent Media Data Platform)
-* MetaProtocol-Others：Alauda, Tencent iGame...
+* MetaProtocol-Others: Alauda, Tencent iGame...
 * MetaProtocol-Private protocols: Have a private protocol? No problem, any layer-7 protocols built on top of the [MetaProtocol](https://github.com/aeraki-mesh/meta-protocol-proxy) can be managed by Aeraki
 
 Supported Features:
   * Traffic Management
     * [x] Request Level Load Balancing/Locality Load Balancing (Supports Consistent Hash/Sticky Session)
     * [x] Circuit breaking
-    * [x] Flexible Route Match Conditions (any properties can be exacted from layer-7 packet and used as match conditions)
+    * [x] Flexible Route Match Conditions (any properties can be exacted from layer-7 packets and used as match conditions)
     * [x] Dynamic route update through Aeraki MetaRDS
     * [x] Version Based Routing
-    * [x] Traffic Splittin
+    * [x] Traffic Splitting
     * [x] Local Rate Limit
     * [x] Global Rate Limit
     * [x] Message mutation
@@ -103,7 +103,7 @@ Supported Features:
     * [x] Peer Authorization on Interface/Method
     * [ ] Request Authorization
 
-> Note: Protocols built on top of MetaProtocol supports all above features in Aeraki Mesh, Envoy native filters only support some of the above features, depending on the capacities of the native filters.
+> Note: Protocols built on top of MetaProtocol support all the above features in Aeraki Mesh, Envoy native filters only support some of the above features, depending on the capacities of the native filters.
 
 ## Demo
 
@@ -122,7 +122,7 @@ https://www.aeraki.net/docs/v1.0/install/
 ### Build Aeraki Binary
 
 ```bash
-# build aeraki binary on linux
+# build aeraki binary on Linux
 make build
 
 # build aeraki binary on darwin
@@ -154,7 +154,7 @@ Sincerely thank everyone for choosing, contributing, and using Aeraki. We create
 
 ## Contact
 * Mail: If you're interested in contributing to this project, please reach out to [email protected]
-* Wechat Group: Please contact Wechat ID: zhao_huabing to join the Aeraki Wechat group
+* WeChat Group: Please contact Wechat ID: zhao_huabing to join the Aeraki Wechat group
 * Slack: Join [Aeraki slack channel](https://istio.slack.com/archives/C02UB8YJ600)
 
 ## Landscapes

README.zh-CN.md

@@ -40,23 +40,23 @@
 
 这些问题使得用户难以在服务网格中管理微服务中其他广泛使用的7层协议的流量。例如，在一个微服务应用中，我们可能使用以下协议。
 
-* RPC: HTTP, gRPC, Thrift, Dubbo, Proprietary RPC Protocol …
+* RPC: HTTP, gRPC, Thrift, Dubbo, 私有 RPC 协议 …
 * 消息队列: Kafka, RabbitMQ …
 * 缓存: Redis, Memcached …
 * 数据库: MySQL, PostgreSQL, MongoDB …
 
 ![ 微服务中常使用的七层协议 ](docs/protocols.png)
 
-如果你已经在服务网格中投入了大量的精力，当然，你希望得到它的最大好处--管理你的微服务中所有协议的流量。
+如果你已经在服务网格中投入了大量的精力，你当然希望能够在服务网格中管理所有这些协议的流量。
 
 ## Aeraki 的解决方案
 
-为了解决这些问题，Aeraki Mesh 提供了一种非侵入性的、可扩展的方式来管理任何服务网中的7层流量。
+为了解决这些问题，Aeraki Mesh 提供了一种非侵入性的、高度可扩展的方式来管理任何服务网中的7层流量。
 ![ Aeraki ](docs/aeraki-architecture.png)
 
 正如该图所示，Aeraki Mesh 由以下几部分组成。
 
-* Aeraki: [Aeraki](https://github.com/aeraki-mesh/aeraki) 为运维提供了高层次的、用户友好的流量管理规则，将规则转化为 envoy 代理配置，并利用 Istio 的`EnvoyFilter` API 将配置推送给数据面的 sidecar 代理。 Aeraki 还在控制面中充当了 MetaProtocol Proxy 的 RDS 服务器。不同于专注于 HTTP 的 Envoy RDS，Aeraki RDS 旨在为所有七层协议提供通用的动态路由能力。
+* Aeraki: [Aeraki](https://github.com/aeraki-mesh/aeraki) 为运维提供了高层次的、用户友好的流量管理规则，将规则转化为 envoy 代理配置，并利用 Istio 的`EnvoyFilter` API 将配置推送给数据面的 sidecar 代理。 Aeraki 还在控制面中充当了 MetaProtocol Proxy 的 RDS（路由发现服务）服务器。不同于专注于 HTTP 的 Envoy RDS，Aeraki RDS 旨在为所有七层协议提供通用的动态路由能力。
 * MetaProtocol Proxy: [MetaProtocol Proxy](https://github.com/aeraki-mesh/meta-protocol-proxy) 是一个七层代理框架，为七层协议提供了常用的流量管理能力，如负载均衡、熔断、路由、本地/全局限流、故障注入、指标收集、调用跟踪等等。我们可以基于 MetaProtocol Proxy 提供的通用能力创建自己专有协议的七层代理。要在服务网格中加入一个新的协议，唯一需要做的就是实现 [编解码器接口](https://github.com/aeraki-mesh/meta-protocol-proxy/blob/ac788327239bd794e745ce18b382da858ddf3355/src/meta_protocol_proxy/codec/codec.h#L118) （通常只需数百行代码）和几行 yaml 配置。如果有特殊的要求，而内置的功能又不能满足，MetaProtocol Proxy 还提供了一个扩展机制，允许用户编写自己的七层过滤器，将自定义的逻辑加入 MetaProtocol Proxy 中。
 
 MetaProtocol Proxy 中已经内置了 [Dubbo](https://github.com/aeraki-mesh/meta-protocol-proxy/tree/master/src/application_protocols/dubbo) 和 [Thrift](https://github.com/aeraki-mesh/meta-protocol-proxy/tree/master/src/application_protocols/thrift) 支持。如果你正在使用一个闭源的专有协议，也可以在服务网格中管理它，只需为它编写一个 MetaProtocol 编解码器即可。
@@ -149,7 +149,7 @@ make docker-build-e2e
 
 ## 谁在使用 Aeraki?
 
-真诚地感谢大家选择、贡献和使用 Aeraki。我们创建这个 issue 是为了收集使用案例，以便我们能够推动 Aeraki 社区向正确的方向发展，以更好地服务于真实的使用场景。我们鼓励您在这个问题上提交评论，包括您的使用方式：https://github.com/aeraki-mesh/aeraki/issues/105
+真诚地感谢大家选择、贡献和使用 Aeraki。我们创建了这个 issue 来收集 Aeraki 的使用案例，以便我们能够推动 Aeraki 社区向正确的方向发展，以更好地服务于真实的使用场景。我们鼓励您在这个问题上提交评论，包括您的使用方式：https://github.com/aeraki-mesh/aeraki/issues/105
 
 ## 联系我们
 * Mail: 如果你有兴趣为这个项目作出贡献，请联系 [email protected]