阿里微服务布道师:详解微服务架构设计( 三 )

  • 单个微服务数据独立 , 可独立部署和运行 。虽然微服务本身是可以独立部署和运行的 , 但仍然避免不了业务上的你来我往 , 这就涉及到要对外通信 , 当微服务的数量达到一定量级的时候 , 如何提供一个高效的集群通信机制成为一个问题 。
  • 单个微服务拥有自己的进程 , 进程本身就可以动态的启停 , 为无缝升级的打好了基础 , 但谁来启动和停止进程 , 什么时机 , 选择在哪台设备上做这件事情才是无缝升级的关键 。这个能力并不是微服务本身提供的 , 而是需要背后强大的版本管理和部署能力 。
  • 多个相同的微服务可以做负载均衡 , 提高性能和可靠性 。正是因为相同微服务可以有多个不同实例 , 让服务按需动态伸缩成为可能 , 在高峰期可以启动更多的相同的微服务实例为更多用户服务 , 以此提高响应速度 。同时这种机制也提供了高可靠性 , 在某个微服务故障后 , 其他相同的微服务可以接替其工作 , 对外表现为某个设备故障后业务不中断 。同样的道理 , 微服务本身是不会去关心系统负载的 , 那么什么时候应该启动更多的微服务 , 多个微服务的流量应该如何调度和分发 , 这背后也有一套复杂的负载监控和均衡的系统在起作用 。
  • 微服务可以独立部署和对外提供服务 , 微服务的业务上线和下线是动态的 , 当一个新的微服务上线时 , 用户是如何访问到这种新的服务?这就需要有一个统一的入口 , 新的服务可以动态的注册到这个入口上 , 用户每次访问时可以从这个入口拿到系统所有服务的访问地址 。这个统一的系统入口并不是微服务本身的一部分 , 所以这种能力需要系统单独提供 。
  • 还有一些企业级关注的系统问题 , 比如 , 安全策略如何集中管理?系统故障如何快速审计和跟踪到具体服务?整个系统状态如何监控?服务之间的依赖关系如何管理?等等这些问题都不是单个微服务考虑的范畴 , 而需要有一个系统性的考虑和设计 , 让每个微服务都能够按照系统性的要求和约束提供对应的安全性 , 可靠性 , 可维护性的能力 。

  • 阿里微服务布道师:详解微服务架构设计

    文章插图
     
    API为什么很重要•服务价值的精华体现
    •可靠、可用、可读
    •只有一次机会
    阿里微服务布道师:详解微服务架构设计

    文章插图
     
    实现一个API网关作为所有客户端的唯一入口 。API网关有两种方式来处理请求 。有些请求被简单地代理/路由到合适的服务上 , 其他的请求被转给到一组服务 。
    阿里微服务布道师:详解微服务架构设计

    文章插图
     
    相比于提供普适的API , API网关根据不同的客户端开放不同的API 。比如 , Netflix API网关运行着客户端特定的适配器代码 , 会向客户端提供最适合其需求的API 。
    API网关也可以实现安全性 , 比如验证客户端是否被授权进行某请求 。
    设计要素•Version
    •RequstID
    •Auth&Signature
    •RateLimit
    •Docs
    •ErrorCode&Message
    阿里微服务布道师:详解微服务架构设计

    文章插图
     
     
    微服务治理•按需伸缩
    –部署与监控运维成本
    •独立部署
    –机器数量与部署成本
    •业务独立
    –服务依赖、治理 , 版本管理、事务处理
    •技术多样性
    –环境部署成本、约定成本
    •运行状态治理
    –监控、限流、SLA、LB、日志分析
    •服务注册与发现
    •部署
    –快速、复制、扩容
    –单机开发
    •调用
    –安全、容错、服务降级、调用延时
    阿里微服务布道师:详解微服务架构设计

    文章插图
     

    阿里微服务布道师:详解微服务架构设计

    文章插图
     
     
    服务容错当企业微服务化以后 , 服务之间会有错综复杂的依赖关系 , 例如 , 一个前端请求一般会依赖于多个后端服务 , 技术上称为1 -> N扇出. 在实际生产环境中 , 服务往往不是百分百可靠 , 服务可能会出错或者产生延迟 , 如果一个应用不能对其依赖的故障进行容错和隔离 , 那么该应用本身就处在被拖垮的风险中 。在一个高流量的网站中 , 某个单一后端一旦发生延迟 , 可能在数秒内导致所有应用资源(线程 , 队列等)被耗尽 , 造成所谓的雪崩效应(Cascading Failure) , 严重时可致整个网站瘫痪 。


    推荐阅读