1. 简介
既然微服务是一种架构风格，那么从总体的技术架构图来理解微服务则再好不过。
2. 总体技术架构图
学习于极客时间，架构师杨波的微服务分享
总体技术架构图从底层到接入层分了六层
- 基础设施层：是软件运行的必要条件，计算、网络、存储、监控、安全、IDC
- 平台服务层：包含图中几个模块，资源治理、集群资源调度配合实际业务场景实现资源充分利用，如业务量暴增时，增加服务，上调资源，需要配合监控告警，理想状态是如何实现自动化，交由系统弹性分配。镜像治理、发布系统帮助实现自动化。IAM （ Identity And Access Management）
- 支撑服务层：后续文章的核心讨论点，也是微服务架构落地与实现的带来的挑战
- 业务服务层：分解为基础服务与聚合服务两个维度
- 基础服务：基于单一职责，根据业务特点沉淀与底层的核心基础服务、公共服务、中间层服务
- 聚合服务：很多时候基础服务是可重复利用的，同时也需要支持需求的多变，通过聚合服务将基础服务关联，组件，再封装，可很好实现目标
- 网关层：可根据访问者类型拆分为图中几类。内部的接口无论出于安全、稳定性、还是设计上的考虑都不应该直接开放给接入层（或者是调用者），引入网关层设计可以很好解决上述问题，并且可通过网关层实现特定需求，如黑名单过滤，鉴权、反向路由等
- 接入层：统一引入LB，可分为外部LB以及内部LB。负载均衡已成为标配，无论是需要充分利用资源，还是控制访问流量。主流的解决方式nginx、f5、软负载等
3. 微服务框架需要为我们解决什么
框架的意义是让我们更专注与业务开发，减少重复工作，提高开发效率。
3.1 微服务框架有什么用
微服务架构分层中，业务服务层才是我们的业务实现代码所在。去除与运维、硬件相关的基础设施层及平台服务层。接入层的LB、网关层、支撑服务层我们都依托于框架，如果有一套完善的微服务框架能帮助我们解决这些与业务无关，但是必须由他们来支撑业务的正常运行的模块，那么对于整体的开发效率的提升是很有帮助的。
3.2 微服务框架具体解决什么
- 负载均衡（软件形式的负载均衡）
- 服务治理
- 集中配置
- 限流熔断
- API网关
- 日志聚合
- 监控告警
- 后台服务
- 认证授权