这里使用商城系统举例，假如系统中有用户管理模块，商品管理模块和订单管理模块
单体架构
将所有的模块都写在同一个项目当中，并且运行在一个web服务中
优点：开发简单，适用于小型的应用
缺点：耦合度高，不易维护和扩展，并且并发能力不强
垂直应用架构
将系统分模块进行开发，运行，如：用户管理独立运行在一台机器上，商品管理运行在另一台机器上
优点：解决高并发问题，可以针对不同的模块进行优化，方便水平扩展，有一定的容错
缺点：系统是相互独立的，可能会有大量的重复开发工作
分布式架构
将系统中的模块分成基础服务应用和业务应用，业务模块通过远程的方式调用基础服务
优点：解耦，高并发，扩展性，可维护性，灵活
缺点：服务的治理以及调度增加难度，增加了系统的复杂度
下面是各个架构的示例图：
SOA架构
解决分布式的的调度，管理问题。就是在业务应用层和服务层之间增加一个管理器，统一通过这个管理器对所有的应用进行管理
SOA架构代表：esb，dubbo
微服务架构
微服务架构其实就是在SOA架构的基础上再进化，将服务再次尽量的拆分，尽量做到每个业务就分成一个服务，而SOA则是尽量将同一种类型的业务分配到一个模块中
微服务代表：springcloud
微服务和SOA的区别
| - | 微服务 | SOA |
|---|---|---|
| 传输方式 | http | RPC |
| 组件大小 | 单独任务或者小块业务逻辑 | 大块业务逻辑 |
| 耦合 | 总是松耦合 | 通常松耦合 |
| 管理 | 着重分散管理 | 着重中央管理 |
| 目标 | 执行新功能、快速拓展开发团队 | 确保应用能够交互操作 |
附录
通讯
RPC
RPC(Remote Procedure Call)一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式(TCP或者UDP)、序列化方式(XML/JSON/二进制)和通信细节。开发人员再使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程
RESTful
通过http协议进行发送，极其灵活
区别
| - | RESTful | RPC |
|---|---|---|
| 协议 | Http | 一般使用TCP |
| 性能 | 略低 | 较高 |
| 灵活度 | 高 | 低 |
| 应用 | 微服务架构 | SOA架构 |
分布式中的CAP原理
C:一致性（多节点数据一致）
A：可用性（保持服务可用：多节点）
P：分区容忍性（是否可以将数据存到多个地方）
一个系统中不可能同时满足C,A,P。所以一般只能满足其中两个
AC：放弃分区容忍，物理数据库
AP：可以短暂允许数据不一致，NoSql数据库
CP：放弃可用性
