一、单体架构
- 所有功能，所有模块都耦合在一个系统里面，如传统的一MVC。 需要重新编译测试，重新部署。
- 伸缩性差
- 可靠性差
- 系统迭代困难
- 跨开发语言程序低
- 团队协作麻烦
二、微服务架构
常见架构风格：
- C/S
- B/S
- 基于组件的架构
- 分层架构
- 面向服务的架构 SOA
微服务， 是一种架构风格；
- 是系统1对多服务
- 每个服务独立部署
- 每个服务高内聚（每一个服务只做一件事）
- 服务间低耦合
优点
- 服务独立，可以独立测试与部署
- 服务水平扩展容易
- 服务松耦合，不会因某个BUG，而导致整个系统宕机
- 小团队开发， 不同团队分开开发， 迭代方便
- RESTFUL接口， 语言无关。
- 团队按微服务配置， 团队合作方便
缺点
- 运维成本高
- 接口需要兼容多个版本
- 分布式系统的复杂性
- 分布式事务
三、MVC、RPC、SOA微服务架构区别
MVC
idea 试错， 快速验证， 简单快速上线。
JAVA系列，常用STRUCT/SPRINGMVC/MYBATIS等
RPC
解体单上述的单体架构，抽取核心服务，独立关键技术。
Trift/Avro/Hessian/Protobuf/
Thrift开源跨语言接口。
Avro RPC接口
SOA
多了一个ESB中介服务。
微服务
上述出现了问题是， 服务太多，如何管理。ESB过度到了zk/eureka(注册中心)。
四、如设计服务，如何分解
拆分原则 AKF扩展立方体
Y轴(功能)： 就是按功能，按业务拆分
X轴(水平扩展)： 就是同一个服务运行多个实例， 做个集群加负载均衡
Z轴(数据分区)： 基于类型的数据分区，如果用户所有区域。重庆，成都各一个集群。
前后端分离
就是把前后端的代码分离， 物理分离， 只用接口和模型。如前端可以用MVVM架构，和后端只是简单RESTFUL接口。
无状态服务
对于无状态服务， 首先说一下什么是状态， 如果一个数据需要被多个服务共享，才能完成一笔交易， 那么这个数据被称为状态， 进而依赖这个“状态”数据的服务被称为有状态服务， 反之称为无状态服务。
真实意思，就是把有状态业务改变成为状态无关的计算服务， 数据迁移到分布式缓存中存储， 让业务服务变成了一个无状态的计算节点。这样就可以做水平扩展了。动态添加与删除节点。不再需要考虑数据同步的问题了。
RESTFULL 无状态通信
- HTTP，扩展能力强，可以扩展成HTTPS
- 行业通用