1.1 传统的单体应用

所谓单体应用程序，通俗来说就是把所有功能全部堆积在一起。这个应用大部分都是一个WAR包或者JAR包。以笔者自己搭建的技术网站“猿天地”为例，用户、文章、源码、课程都是在一个项目中的。随着业务的发展，功能的增加，多年以后这个单体项目将变得越来越臃肿。

这样的单体应用在公司创建初期是一种比较好的方案，要快速增加新功能或部署发布都比较简单。不过，随着时间的推移，危机也会慢慢显露出来。任何一个BUG都可能导致整个应用瘫痪，正所谓牵一发而动全身。

1.1.1 改进单体应用的架构

架构总是通过演变而来的，既然传统的单体应用架构不能满足业务的发展，那么架构的改变必然会提上日程。在系统不能支撑当前的用户量后，我们将项目按照不同的业务来做拆分，分成多个子系统，系统之间通过Webservice或者HTTP接口来进行交互，这样做的好处是系统不再那么臃肿了。

随着用户量越来越多，系统的压力也随之增长。可能其中某一个模块使用的频率比较高，这个时候就需要对这个模块进行扩展，其实就是多部署几个节点。前面再加一个Nginx用于负载均衡，刚开始还没什么大问题，当子系统越来越多的时候，每个子系统前面都要加一层负载，对运维人员来说工作量就增加了，因为要维护的也增多了。

1.1.2 向微服务靠拢

前面讲了这么多，还是不能满足互联网公司快速发展的需求，比如高并发、高可用、高扩展。于是基于之前的架构又改进了一番，引入了阿里巴巴开源的Dubbo框架，解决了服务之间的调用问题，服务调用方不再需要关注服务提供方的地址，只要从注册中心获取服务提供方的地址即可。

目前国内很多公司的微服务架构都是基于Dubbo构建的，为什么我们要转向Spring Cloud ？可以从下面几个方面进行分析：

❑ 社区的支持：

▪ 首先Spring Cloud有强大的社区支持，在Java生态圈必定离不开Spring，且Spring Cloud的更新频率也越来越高。

▪ Dubbo虽然出自阿里巴巴，但是有很长一段时间没维护了，原因是内部有另一个RPC的框架HSF，所以Dubbo被抛弃了，不过去年Dubbo又重回大众视野，对使用开源框架的用户来说，社区对框架的持续维护非常重要，所以笔者认为Spring家族的产品更适合中小型公司。

❑ 关注内容：

▪ Spring Cloud关注的是整个服务架构会涉及的方方面面，在Spring Cloud中各种组件应有尽有，从而使其具有可快速集成、方便、成本低等优势。

▪ Dubbo关注的更细一些，只针对服务治理，相当于Spring Cloud中的一个子集。能和Dubbo相互比较的应该是gRPC, Thrift之类的框架。

❑ 性能问题：

▪ 对于性能这块，Dubbo确实要比Spring Cloud好，原因大家也都清楚，Dubbo基于Netty的TCP及二进制的数据传输，Spring Cloud基于HTTP, HTTP每次都要创建连接，传输的也是文本内容，自然在性能上有些损耗。

▪ Spring Cloud带来的性能损耗对于大部分应用来说是可以接受的，而它具有的HTTP风格的API交互，在不同的语言中是通用的，且对每个微服务的测试来说是非常方便的，也就是说Spring Cloud用小的性能损耗换来了更多好处。当当网在Dubbo的基础上加上REST的支持扩展出目前的Dubbox也是这个道理。