单体架构的利与弊
一般的单体架构采用(MVC)三层模型：
CONTROLLER(控制层或表现层)
用于和用户交互接收用户请求
SERVICE(服务层)
用于处理业务逻辑 处理后的数据返回出去 最终通过表现层展现给用户
DAO(数据层)
用于操作数据
单体架构的好处
单体架构一般只需一台服务器就可以部署全部的资源 这种架构性价比高 开发速度快 开发成本低 只需一台服务器 就可以让项目部署上去
单体架构的不足
单体架构在开发速度和运维程度都有明显的优势 但是也有不足的地方
1.不易扩展和维护
随着业务的需求 代码量越来越大 代码的可维护性 可读性下降
2.并发能力有限
随着项目上线 用户越来越多 单体架构承受的并发有限 如果太多的用户同时访问 容易造成服务器雪崩
微服务
什么是微服务?
1.按业务划分为一个独立运行的程序 即服务单元
2.服务之间通过HTTP 协议相互通信
3.自动化部署
4.可以用不同的编程语言
5.可以用不同的存储技术
6.服务集中化管理
按业务划分为一个独立运行的程序 即服务单元
一个模块可以分成多个模块 多个模块可以分成若干个小的模块 这些模块都是独立运行 服务与服务之间没有任何耦合
通过HTTP 协议相互通信
微服务单元之间的通信方式一般倾向于使用HTTP 这种简单的通信机制，更多的时候是使用RSTfulAPI
其它语言通过RSTful风格访问微服务 服务接收请求处理完成 返回json或者xml各式的数据即可
微服务的数据库独立
微服务之间无耦合 就连数据库都是独立的 每个微服务都有自己独立的数据库 数据库之间没有联系 这样做的好处是 数据库独立 数据量少 易于维护 数据库性能明显提升 迁移也非常方便
服务集中化管理
随着服务越来越多管理起来越来越复杂 因此微服务需要集中管理 一般采用注册中心来管理服务
微服务的优势
1.将一个复杂的业务拆分成若干个小的业务 将复杂的问题简单化 代码的扩展性和可读性增加
2. 由于微服务是分布式系统 服务于服务之间的没有任何的耦合度 具有很强的横向扩展能力
3. 微服务之间通过HTTP来通信 服务于服务之间完全独立 可以用任何开发语言和技术来实现 开发者可以选用自己适合的语言 提高开发效率 降低开发成本
4. 微服务都是独立部署的 即独立运行在某个进程里 微服务的修改和部署对其它服务没影响 如果是单体应用 则需要测试和部署整个项目
5. 微服务在CAP理论中 采用AP架构 即高可用和分区容错性
微服务的不足
1.微服务的复杂度
微服务是分布式系统 构建的复杂程度超过单体应用
2.分布式事务
分布式系统有一个著名的CAP 理论 即同时满足 Consistency 一致性 Availability 可用性 和 Partition-tolerance 分区容错性 是不可能的 在分布式系统中P是基本要求 单体服务是CA系统
在微服务中 每个服务都是独立运行的 每个服务都有自己的数据库如果是微服务架构，账户是一个服务 而商品是一个服务 这时不能用数据库自带的事务 因为这两个数据表不在一个数据库中