最近发现，组内的小伙伴对负载均衡组件有哪些还不清楚，总结了下，希望对大家能有写用处。
当用户点击了一次页面，到后端server执行完返回，经过了好几次传递，每次上游调用下游，都要使用负载均衡组件。
使用负载均衡组件有什么好处？
- 自动选择存活的服务器，剔除掉“死掉”的服务。
- 保证请求能够按照分配均匀地分给服务端。
- 服务端增减机器，修改配置，对客户端透明。
以上几点最深的体会就是。
作为服务端，不必急急忙忙地恢复死掉的服务，只要有存活的节点存在即可。因为有时你可能正在吃饭或睡觉。
作为客户端，服务端更换你不必配合发布，减少工作量，代码不用做业务外的特殊逻辑。
下面我们从前到后一次看看都有哪些组件供我们使用。
如图所示，用户发起请求时，先从dns获取域名的真实ip，然后用真实ip来访问web服务器。用到了tgw组件。tgw对外是一个外网ip，后端挂载了多个内网实体ip。tgw会定期检测后端真实ip的服务是否存活，通过负载算法，选择存活的ip来进行访问。用户的请求会经过tgw，但是对用户来说是透明的。tgw的好处是节约外网ip，一个ip可以把一个机房的机器都挂载上。增减web server速度快，正常dns刷新要几小时到几天才全更新。
请求到了web server后，需要使用后端server提供的接口服务。通过CMLB组件来拉取后端的所有ip和负载分配配置，调用sdk来选择出一个最合适的ip，然后web server使用这个ip来访问后端。要接入CMLB，需要使用CMLB的sdk，在请求之前获取一次ip。虽然多加了几行代码，但是这种方式简单直观，还是web sever直接链接的后端。组件只起到了更新配置的作用。
但是在链接数据库，redis这些场景中，有些时候ip是写到php配置文件，或者框架配置文件中的。没有办法“多加几行选择ip的代码”。这时LB组件出现了，和tgw类似，只是都是内网ip。对服务调用方来说就是一个ip，只是在调用的过程中经过了LB的服务器做代理，他来透明的把请求转到后端适合的数据库服务器上。
用LB还有个注意的地方，通常LB为了节约资源，定3小时如果链接不使用，那么会自动断掉链接，对于客户端和服务器都是没有感知的，只有在下次调用时发现链接不存在了。所以要监控链接的返回值，发现连不上要重连。
又有个问题，CMLB和LB功能类似，是否可以互相替代呢？
答案是可以互相替代。LB是后来腾讯云出品的，如果没有CMLB完全可以用LB来实现同样的功能。CMLB在内部已经使用很多，相应的组件和监控也非常成熟。对于能控制代码获取ip的地方，使用CMLB。对于在配置中等写死ip的场景，使用LB。
总结
| 组件名称 | 使用场景和方法 |
|---|---|
| tgw | 服务外网域名服务使用，同一个机房的服务器挂载到一个tgw的虚ip上。如果有提供https服务，需要把证书上传到tgw配置网页。在nginx上只提供http服务就可以。tgw会帮助做ssl校验和转换成http服务给后端。 |
| CMLB | 使用agent拉取远端配置ip列表，本地调用sdk获取最适合的ip和程序。 |
| LB | 和tgw类似，是内网版。可以给数据库、队列挂载LB的虚ip。要监控链接断开。 |