微服务概述之集群架构

集群架构的由来

随着业务的发展，系统的压力越来越大，对设备的配置要求也越来越高，工程师们不断上线性能更高的服务器，而高端点的计算设备又非常昂贵，如IBM 的Power 系列小型机，一台就需要十几万美元，这对于小型企业来说是不能承受的，如阿里巴巴的淘宝就经历过“去IOE”的过程，“去IOE”是阿里巴巴公司提出的概念，其本意是在阿里巴巴的IT架构中，去掉 IBM的小型机、Oracle 的数据库、EMC的存储设备，代之以自己公司在开源软件基础上开发的系统。这其中的原因包括设备购买的费用昂贵、设备的维护需要专业的人员，以及维护的服务费也比较高。并且，由于有摩尔定律，处理器的性能每隔两年翻一倍，单台机器性能发展得再快，也跑不过业务的指数级发展。

为什么要去IOE

单体应用的部署可能还会造成硬件资源的浪费。例如，在用小型机部署系统时，系统在1月份只需要10GB 内存，预计在“双11”时会达到100GB 内存的需求，这样企业就需要为将来的业务预留100GB 的内存配置，如此就会造成在一段时间内有90GB内存的浪费。
如果到“双11”时，业务真正达到了100GB 内存的需求还好，没有浪费内存，如果达不到呢，90GB 内存就白白浪费了。
基于以上提到的两点问题，能想到的解决方案如下。

1. 机器昂贵。通过分解化整为零，使高配的机器由众多低配的机器来组成，从而解 决成本问题。
2. 资源浪费。将配置进行适时的增加。在合适的时候，再采用合适的配置。如到“双 11”的时候，再进行配置的增加。

集群架构的应运而生

当时市场上有很多价格便宜的普通PC，和小型机相比而言，虽然普通PC的8GB 内存比不上小型机的128GB 内存的性能，但是两者的计算架构是一样的，能实现的计算功能是一样的，而 PC 的价格劫要比小型机便宜很多。于是聪明的工程师们又想出了一种廉价的解決方案，将很普通PC集群到一起，这就是集群架构，这样一来，一方面可以将小的力量汇聚成大的力量，大大降低了采购小型机的成本；另一方面当需要增加配置时，再增加机器即可，即减少了资源闲置和浪费。后来大多数公司都采取了集群架构进行系统部署，通过增加负载均衡服务器，如硬件负载均衡F5、软件负载均衡 Nginx 等来进行系统架构的搭建。

负载均衡的作用

负载均衡往往对外暴露一个统一的接口，让外界用户感觉是在向一台服务器发起请求，而实际上通过负载均衡已经将请求分发到了后端不同的服务器上。并且负载均衡还可以进行服务器的健康检查，当有新机器加入时，可以将流量进行动态地分配；当有服务器宕机时，也可以从负载均衡中将其剔除。这样一来，如果想让服务负载原来2倍的访问量，只需要横向、水平扩容1倍的服务器即可。
由于有了统一的入口，因此可以在这个入口进行流量清洗，可防DDoS 攻击。

集群思想的用处

这种集群的思想不仅适用于服务器，也适用于缓存和数据库。例如，有的系统为了提高查询效率，还增加了缓存服务器（主从备份）：有的系统为了缓解数据库压力，进行数据库的读写分离（一主多从）。通过这些方法可应对用户量的增加对系统带来的压力，此时的集群架构部署如下图所示。

集群架构的弊端

集群架构虽然具备一定的处理高并发的能力，改善了系统的性能，但是从业务的角度来看，它依然是部署在不同机器上的一模一样的服务，其本质上还是一个单体的架构，所有的功能都糅合在一个项目中。随着业务的发展，软件服务的功能越来越复杂，物极必反，它的优点随着软件行业的发展，也变成了它的缺点，集群架构的弊端逐渐明显。

1. 开发风险高。随着业务越来越复杂，代码量越来越大，在以后需要升级系统时，即使改动一行代码，也需要重新编译部署整个项目，如果改动还影响到了其他模块，则会有比较大的隐患，因此改动代码的风险非常高。
2. 测试成本高。由于都在一个服务中，不确定改动是否会对其他功能造成影响，所以每一个小小的改动，都需要做全量测试，从而额外增加了测试的成本。
3. 部署频率低。由于开发的风险高，需要测试的成本高，从而导致更新频率变慢，所以不能经常部署，而现在软件更新迭代的频率又非常高，这样就无法满足对客户快速交付的需求。

当然还有很多问题。例如，由于所有功能都在一个项目中，不同功能对硬件的要求也是不同的，有的功能处理文件较多，是IO密集型，有的功能计算功能较多，是CPU 密集型，如果在单体应用中，它们又都是在一个项目中，就无法针对不同的功能，进行硬件资源的合理分配，这样就会造成一定程度的硬件资源的浪费。

总结

另外，如果通过负载均衡部署了10个服务，而每个服务里面都有用户登录功能，当需要对用户登录功能进行升级时，这10个服务也都需要同时升级，这种重复建设显然是一种浪费。
在软件开发领域，重复建设是不可取的，为了解决这些问题，微服务架构应运而生，下一篇给大家讲解微服务架构。