服务化架构的演进历史
Dubbo官网上的一张图
1 单体应用架构
部署到一个war里
部署到一个web容器里（如tomcat）
公用一个DB
优点：
容易测试
容易部署
缺点：
开发效率低
代码维护难
部署不灵活（如构建时间特别长，如任意小的修改，需要重新构建整个项目）
稳定性不高（如任一一个小问题，可能让你整个系统挂掉）
扩展性不够（如购物场景，商品服务和订单服务，浏览的人比下单的人多，商品服务的流量会大一点。如果是微服务，商品服务部署10台，订单服务部署5台）
如下图架构图：
2、MVC（垂直应用架构体系）
主要解决前后端、界面、控制逻辑和业务逻辑的分层问题。
比较流行的技术栈SSM，SSH等。
解决了单一架构面临的扩容问题，流量可以分散到各个子系统中，且体积可控，提高了开发效率。
缺点：垂直应用越来越多，应用间的相互交互，相互调用已无法避免，不同系统之间存在重叠的业务。
3、RPC
随着业务发展，业务规模的扩大，模块化逐步成为一种趋势。此时解决模块之间远程调用的RPC应用而生。
缺点： RPC本身不负责服务化。例如自动发现不管，服务的应用和发布不管、服务运维和治理不管。
4、SOA
为了解决垂直应用架构重复造轮子，提取出来作为单独的系统对外提供服务，形成业务之间的相互重用，这是SOA就出现了。（面向服务的体系价架构）
SOA服务化架构，企业级资产重用和异构系统间的集成对接。
SOA架构的现状
在传统企业IT领域，主要是解决异构系统之间的互通和粗粒度的标准化（WebService）
互联网领域，提供一套高效支撑应用快速迭代的服务化架构。例如各个互联网公司自研或者开源的分布式架构
如下图架构图：
5、微服务
微服务是一种架构风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。
特征如下：
1）小，且只干一件事情
2）独立部署和生命周期管理
3）异构性
4）轻量级通信。RPC或者Restful
如下图架构图：
