Closing channels alone is not an adequate solution to rebalancing because all it does is shift the problem around.
Consider the following scenario: You have a node A, which is a store-front, and a personal node B, which is private. You have private channels i and j between the two nodes. There are some channels you have open on your store front, 1, 2, and 3, each of which has channels open with x, y, z respectively. Also, your personal node has channels open with w and v.
I'll use = to indicate the outbound capacity your merchant node has, and - to indicate the inbound capacity.
(x)----|====(1)----|==== ====|---- ====|----(w)
\ / i \ /
(y)----|====(2)----|==== (A) (B) ====|----(v)
/ \ j /
(z)----|====(3)----|==== ====|----
Assuming all channels have a capacity of 8ksat above, and are all evenly balanced, lets see what happens if z makes a payment of 4ksat.
(x)----|====(1)----|==== ====|---- ====|----(w)
\ / i \ /
(y)----|====(2)----|==== (A) (B) ====|----(v)
/ \ j /
(z)|========(3)|======== ====|----
The inbound capacities of the channels between z, 3 and your merchant node A are now exhausted and you will not be able to receive payments through it. To rebalance this, you need to make a payment through 3 and z, to be received via w or v. Lets say we split this into two payments via both w and v.
2ksat: A -> 3 -> z -> ... -> w -> B(i)-> A
2ksat: A -> 3 -> z -> ... -> v -> B(i)-> A
(x)----|====(1)----|==== ========| ======|--(w)
\ / i \ /
(y)----|====(2)----|==== (A) (B) ======|--(v)
/ \ j /
(z)----|====(3)----|==== ====|----
Channel i is now exhausted, so we can close it to cash out on chain. However, we need something to replace it. We need a new channel k, with the same capacity of 8ksat.
(x)----|====(1)----|==== |-------- ======|--(w)
\ / k \ /
(y)----|====(2)----|==== (A) (B) ======|--(v)
/ \ j /
(z)----|====(3)----|==== ====|----
Notice that We've not actually gained anything "on-chain", because we've had to reuse those funds to establish the replacement channel, although we still own the money, it is tied up in the channel.
Assume that now x makes a payment of 4ksat, and we repeat the process above, but using j instead of i as the channel we're going to cash out with.
(x)|========(1)|======== |-------- ======|--(w)
\ / k \ /
(y)----|====(2)----|==== (A) (B) ======|--(v)
/ \ j /
(z)----|====(3)----|==== ====|----
2ksat: A -> 1 -> x -> ... -> w -> B(j)-> A
2ksat: A -> 1 -> x -> ... -> v -> B(j)-> A
(x)----|====(1)----|==== |-------- ========|(w)
\ / k \ /
(y)----|====(2)----|==== (A) (B) ========|(v)
/ \ j /
(z)----|====(3)----|==== ========|
We can cash out j and create l in its place, but we have the issue that the channels B had with w and v are now completely exhausted of incoming capacity. We won't be able to rebalance anything else if y makes the same payment.
(x)----|====(1)----|==== |-------- ========|(w)
\ / k \ /
(y)|========(2)|======== (A) (B) ========|(v)
/ \ l /
(z)----|====(3)----|==== |--------
So unless B is actively spending on the lightning network, through w and v, those channels are not going to be reusable for rebalancing. It isn't possible to spend from B back to A via these channels, as that would exhaust the inbound capacities of its other channels it has open to customers.
In practice, you will probably have more channels open, and each node will be routing payments for other people, so you may have some other rebalancing going on. You might discover that certain paths are used more frequently one direction than another, which would make it ideal for use as a rebalancing path.
However, the end goal is eventually to not need to cash out - but to make your purchases directly on the network. Likewise, you should be able to get paid over the network, and rebalancing will become less of an issue as the number of channels increases, and liquidity increases.
There are a number of services which can be used to "refill" channels, in return for direct on-chain payments. I guess there is a market for the opposite of such service too - to offload payment channels in return for the on-chain payment. There have been some proposals for liquidity markets to be developed directly on the Lightning Network layer so that some of this can be automated in future.
Perhaps the correct thing to do, is not to attempt to rebalance unless absolutely necessary for yourself though. In the above scenario, when z first paid, instead of trying to rebalance the channel A has open with 3, you could just close this channel and cash out. If z wants to make another payment to you, they must either do it through 1 or 2, or some other channel which might be created with incoming capacity in your direction. The problem then is not your's, but z's. If you are a useful routing node, then people will probably want to open more channels with you with inbound capacity to you also.
1, 2, and 3 are not necessarily your customers. Your customers are x, y and z, and the direct channels you have open just facilitate those payments.
