缘起##
在很多微服务架构的例子中强调了很多单体应用的场景。主要是因为在实际中一个应用系统里面的模块没有办法做到彻底解耦，如果要实现按组件单独部署是不可能的，相互之间仍然有大量内部不可见依赖而导致了模块间无法拆分。
单体应用带来的问题
- 系统复杂，内部多个模块紧耦合，牵一发而动全身。
- 运维困难，变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体出现故障。
- 无法扩展，无法拆分部署，出现性能瓶颈后往往只能增加服务器或增加集群节点，但是DB问题难解决
引入微服务
正是由于这些原因需要考虑引入微服务架构（实质仍然是单个应用本身的组件化和服务化），对于微服务文章里面有一个详细说明如下：一个微服务一般完成某个特定的功能，比如订单管理，客户管理等。每个微服务都是一个微型应用，有着自己的六边形结构，包括商业逻辑和各种接口。有的微服务则通过暴露API被别的微服务或者应用客户端所用。有的微服务则通过网页UI实现。在运行时，每个实例通常是一个云虚拟机或者Docker容器。
微服务核心三点
- 足够构成一个独立小应用
- 微服务之间只能通过ServiceAPI进行交互
- 一般运行在云虚拟机或更轻的Docker容器上
Gateway
Gateway，这实际上微服务架构里面的很重要的内容，其作用类似于传统企业内部的ESB服务总线，只是更加轻量和高性能来解决微服务的管控和治理问题。对于负载均衡，缓存，路由，访问控制，服务代理，监控，日志等都属于基本的服务管控内容，也是APIGateway需要考虑的核心能力。
Scale Cube 3D模型
- Y轴：本质是应用的分解，即将传统的单体应用分解为多个微服务应用
- X轴：水平弹性扩展能力，即通过负载均衡来实现水平弹性扩展，但是DB问题无法解决
- Z轴：单个微服务应用引入了DB弹性扩展能力要解决时，我们引入了对数据库进行拆分和Daas
整个模型描述了通过微服务架构实施后可扩展性的变化
微服务架构的不足
- CAP原则：由于服务无状态和引入了分布式，较难解决事务一致性问题。
- 集成原则，任何彻底的分解都将带来集成的复杂度，即模块在集成时候需要外部微服务模块更多的配合。
- 部署问题，稍大项目都涉及上100个服务节点部署，还涉及到部署后的配置，扩展和监控问题。
