一、单体架构
- 所有功能,所有模块都耦合在一个系统里面,如传统的一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
- 行业通用