Spring架构-01-微服务架构

一、单体架构

• 所有功能，所有模块都耦合在一个系统里面，如传统的一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
• 行业通用