This is an automated email from the ASF dual-hosted git repository.
iluo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new be8f24c fix typo and fix issue #587 (#586)
be8f24c is described below
commit be8f24ca5c978813dbf7c7bf80cdb97db3ac3a90
Author: Zebulon Feng <[email protected]>
AuthorDate: Thu Aug 6 14:32:49 2020 +0800
fix typo and fix issue #587 (#586)
* fix typo
* Fix typo in architecture.md
* Fix issue #587
Co-authored-by: zhangjianghao <[email protected]>
---
docs/en-us/user/preface/architecture.md | 2 +-
docs/en-us/user/preface/requirements.md | 2 +-
docs/en-us/user/quick-start.md | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/docs/en-us/user/preface/architecture.md
b/docs/en-us/user/preface/architecture.md
index 90fdef7..92865f2 100644
--- a/docs/en-us/user/preface/architecture.md
+++ b/docs/en-us/user/preface/architecture.md
@@ -41,7 +41,7 @@ Dubbo has the following features: Connectivity, Robustness,
Scalability and Upgr
* `Register` is a peer cluster, it will automatically switch to another when
any instance goes down
* Even all `Register`'s instances go down, `Provider` and `Consumer` can still
conmunicate by checking their local cache
* Service `Provider`s are stateless, one instance's downtime doesn't affect
the usage
-* After all the `Provider`s of one service go down, `Consumer` can not use the
that service, and infinitely reconnect to wait for service `Provider` to recover
+* After all the `Provider`s of one service go down, `Consumer` can not use
that service, and infinitely reconnect to wait for service `Provider` to recover
## Scalability
diff --git a/docs/en-us/user/preface/requirements.md
b/docs/en-us/user/preface/requirements.md
index 1695988..004e786 100644
--- a/docs/en-us/user/preface/requirements.md
+++ b/docs/en-us/user/preface/requirements.md
@@ -2,7 +2,7 @@
-Before the advent of large-scare services, an application might just exposes
or references remote service by using RMI or Hessian, the call is done by
configuring service URL, and load balance is done through hardwares, like F5.
+Before the advent of large-scale services, an application might just exposes
or references remote service by using RMI or Hessian, the call is done by
configuring service URL, and load balance is done through hardwares, like F5.
**When there are more and more services, it becomes very difficult to
configure the service URL, the single point pressure of F5 hardware load
balancer is also increasing.** At this point, a service registry is needed to
dynamically register and discover services to make the service's location
transparent. By obtaining the list of service provider addresses in the
consumer side, the soft load balancing and Failover can be realized, this
reduces the dependence on the F5 hardware load bala [...]
diff --git a/docs/en-us/user/quick-start.md b/docs/en-us/user/quick-start.md
index bbf0b14..71e4955 100644
--- a/docs/en-us/user/quick-start.md
+++ b/docs/en-us/user/quick-start.md
@@ -248,5 +248,5 @@ You can find the complete example code in the Github
repository.
* [Consumer demo](../admin/install/consumer-demo.md)
[^1]: The interface needs to be packaged separately, shared by the service
provider and the consumer
-[^2]: Hidden realization of service consumer
-[^3]: IoC injection can also be used
+[^2]: Hidden realization for service consumer
+[^3]: IoC injection can also be used
\ No newline at end of file
