Requirements

 

 

 

 

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.

在大规模的服务降临之前，一个应用只是通过RMI或则Hession暴露或则引用远程服务，服务通过配置服务URL(Uniform resource locator )调用，并且负载均衡是通过硬件，比如 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 balacer and some of the costs.

当服务越来越多时，配置服务URL变动异常困难，同样H5硬件负载均衡的单点压力也在增加。此时为了让服务地址透明，一个用于动态注册和方向服务的注册中心迫在眉睫。在消费端获取服务端地址的列表，可以实现软负载均衡和容错，这可以减少对F5负载均衡和其他的消耗。

When things go further, the service dependencies become so complex that it can't even tell which applications to start before, even the architect can't fully describe the application architecture relationships. At this time, automatically draw the dependency diagram of the applications is needed to help the architect to be clear of the relationship.

当发展到下一步时，服务依赖变得非常复杂，甚至都没法说出要先启动哪个应用，甚至架构师都没法完全描述应用架构关系。此时，为了帮助架构师清晰的知道关系架构关系，一个自动渲染关系图的程序迫在眉睫。

Then, the traffic becomes even heavier, the capacity problem of the service is exposed, how many machines are needed to support this service? When should the machine be added? To solve these problems, first, the daily service calls and the amount of response time should be counted as a reference for capacity planning. Second, dynamically adjust the weight, increase the weight of an online machine, and recorded the response time changes until it reaches the threshold, record the visits times at this time, then multiply this number of visits by the total number of machines to calculate the capacity in turn.

当流量高峰时，服务的容量问题会暴露出来，需要多少机器来支持这个服务？什么时候该添加机器？为了解决这个问题，首先，每日调用服务量和响应时间次数需要累计出来作为容量计划安排的参考。其次，动态的调整权重，增加在线机器的权重，记录响应时间的变化直到到达阈值，记录此次的访问时间，然后用机器的总数量乘以这个访问时间去依次计算容量。

Above are the most basic requirements of Dubbo.

以上是dubbo的最基本的要求。