微服务架构

微服务架构

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发、设计、运行和运维的小应用

SOA 和微服务的区别：

• 微服务不再强调传统 SOA 架构里面比较重的 ESB（企业服务总线 ）
• SOA 的思想进入到单个业务系统内部实现真正的组件化

单体应用本身带来的主要问题

• **系统复杂：**内部多个模块紧耦合，关联依赖复杂，牵一发动全身
• **运维困难：**变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体运行故障
• **无法扩展：**无法拆分部署，出现性能瓶颈后往往只能够增加服务器或增加集群节点，但是数据库的问题难以解决

引入微服务架构

正是由于单体应用本身带来的问题，考虑引入微服务架构

微服务特点：

• 一个微服务一般完成某个特定的功能，比如订单管理、客户管理
• 每个微服务都是一个微型应用，有着自己的六边形架构，包括商业逻辑和各种接口
• 微服务通过暴露 API 被别的服务或者应用客户端所用
• 在运行时，每个实例通常是一个云虚拟机或者 Docker 容器

微服务核心

• 其一足够构成一个小应用（从 DB 到 UI）
• 其二微服务应用之间只能通过 Service API 进行交互
• 其三一般运行在云虚拟机或更轻的 Docker 容器上

API Gateway

实际上是微服务架构里面的很重要的内容，其作用类似于传统企业内部的 ESB 服务总线，只是更加轻量和高性能来解决微服务的管控和治理问题

去中心化和全分布式架构中，网关成了一个中心点或瓶颈点，所以需要考虑网关宕机也不要影响到服务的调用和运行

基本服务管控内容

• 负载均衡
• 缓存
• 路由
• 访问控制
• 服务代理
• 监控
• 日志

可扩展的立方体 3D 模型

即通过微服务架构实施后扩展性的变化

• **X轴：**水平弹性扩展能力，即通过负载均衡来实现水平弹性扩展，但是 DB 问题无法解决
• **Y轴：**本质是应用的分解，即将传统的单体应用分解为多个微服务应用
• **Z轴：**当微服务应用引入了 DB 扩展问题的时候，可以对数据库进行拆分

微服务的不足

• **CAP原则：**由于服务无状态和引入了分布式，较难解决事务一致性问题
• **集成复杂：**任何彻底的分解都将带来集成的复杂度，即模块在集成时需要外部微服务更多的配合
• **部署问题：**稍大项目都涉及到大量服务节点部署，还涉及到部署后的配置，扩展和监控问题