MicroService--Architecture

总体技术架构图从底层到接入层分了六层

基础设施层：是软件运行的必要条件，计算、网络、存储、监控、安全、IDC
平台服务层：包含图中几个模块，资源治理、集群资源调度配合实际业务场景实现资源充分利用，如业务量暴增时，增加服务，上调资源，需要配合监控告警，理想状态是如何实现自动化，交由系统弹性分配。镜像治理、发布系统帮助实现自动化。IAM （ Identity And Access Management）
支撑服务层：后续文章的核心讨论点，也是微服务架构落地与实现的带来的挑战
业务服务层：分解为基础服务与聚合服务两个维度
基础服务：基于单一职责，根据业务特点沉淀与底层的核心基础服务、公共服务、中间层服务
聚合服务：很多时候基础服务是可重复利用的，同时也需要支持需求的多变，通过聚合服务将基础服务关联，组件，再封装，可很好实现目标
网关层：可根据访问者类型拆分为图中几类。内部的接口无论出于安全、稳定性、还是设计上的考虑都不应该直接开放给接入层（或者是调用者），引入网关层设计可以很好解决上述问题，并且可通过网关层实现特定需求，如黑名单过滤，鉴权、反向路由等
接入层：统一引入LB，可分为外部LB以及内部LB。负载均衡已成为标配，无论是需要充分利用资源，还是控制访问流量。主流的解决方式nginx、f5、软负载等

微服务框架让我们更加专注于业务开发，减少重复工作，提高开发效率

微服务框架分层结构中，业务服务层才是我们的业务实现代码所在。去除与运维，硬件相关的基础设施层以及平带服务层。接入层的LB，网关层，支持服务层我们都依托于框架，如果有一套完善的微服务框架能帮助我们解决这些与业务无关，但是必须有他们来支撑业务的正常运行的模块，那么对于整体的开发效率的提升很有帮助。

微服务框架帮我们解决：
负载均衡（软件形式的负载均衡）
服务治理
集中配置
限流熔断
API网关
日志聚合
监控告警
后台服务
认证授权