服务网格基础-知识篇

技术采用生命周期

技术炒作周期

一、微服务的出现及治理方式演进

1、程序架构概述

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计
架构的形式和特点：
◼ 以文档和代码呈现：设计过程+设计的产物，可以是各类设计文档、设计图，也可是一些技术验证代码、Demo或其它相关的程序；文档是设计的载体，而代码是系统功能实现的载体；
◼ 架构服务于业务：架构设计需要一定的前瞻性来容纳业务的变动；
◼ 架构影响团队的组织形式：业务的拆分方法和技术框架的选择必然会影响研发团队的组织形式，反过来，研发组织的结构和成熟度也会对最终所采取的技术架构产生重要的影响；
◼ 架构存在于每一个系统：每一个已经实现并运行的系统，必然是特定架构设计的载体；
◼ 每个架构都有特定的架构风格
◼ 架构需要不断地发展演进

2、架构风格

架构风格分类：
◼ 单体架构：整个系统的所有功能单元整体部署到同一进程（所有代码可以打包成一个或多个文件）
◆ 进一步细分：简单单体模式、MVC模式、前后端分离模式、组件模式和类库模式等；
◼ 分布式架构：整个系统的功能单元分散到不同的进程，然后由多个进程共同提供不同的业务能力；
◆ 面向服务的架构（SOA）
◆ 微服务架构（MSA）

3、分布式应用的需求

Bilgin Ibryam将其分为生命周期、网络、状态和绑定四个方面
lifecycle:自动化方式部署、恢复、扩展能力
·Packaging
·Healthcheck
·Deployment
·Scaling缩放
·Configuration
networking：
·Service discovery
·A/B testing,canary rollouts金丝雀发布
·Retry,timeout,circuit breaker
·Point-to-point,pub/sub发布/订阅
·Security,observability可观测性
state:一般我们认为，服务最好是无状态的；但管理服务的平台本身却是需要有状态的
·Workflow mgmt工作流
·Idempotency幂等性
·Temporal scheduling临时调度/周期性作业
·Caching
·Application state
binding：
·Connectors
·Protocol conversion协议转换
·Message transformation
·Message routing
·Transactionality交易

4、一图了解分布式架构治理模式演进

SOA(面向服务)/ESB(企业服务总线)–>MSA(microservices)–>云原生(cloud native)

5、SOA提出的分布式系统的构建原则

各服务由规范定义的标准化API提供，这些API通过服务描述的定义将服务消费者的实现与服务提供者的实现进行分离
◼ 服务应该按照契约优先规则而不是代码优先规则来开发
◼ 服务间通信基于面向文档的消息，而非特定语言的RPC协议，从而将服务同其实现语言解耦
各服务彼此独立，它们在时间、空间、技术和团队上是松散的耦合关系
各服务应该是无状态的，这样就可以灵活调用它们，而无须关心不同上下文中的会话状态
各服务应该是自治和自包含的，以便它们可以独立部署、版本控制、自我管理和恢复
各服务可以被发现和组合，例如
◼ 可以通过使用服务注册中心来实现服务发现，从而可以将服务消费者动态绑定到服务提供者
◼ 来自不同系统的业务服务可以在业务流程中进行编排和组装

6、SOA

SOA是建设企业IT生态系统的架构指导思想中的一种，它把服务视作基本的业务功能单元，由平台中立性的接口契约定义；
SOA目前的实现方式有两种：分布式服务化和集中式管理：
◼ 分布式服务化：常见的实现有Dubbo、Finagle和ICE等；
◼ 集中式管理：以ESB为基础支撑技术，较流行的商业实现有WMB (IBM)、OSB (Oracle），开源实现有Mule、ServiceMix和OpenESB等；
SOA的两大基石
◼ RPC：远程过程调用，是一种通用目的系统通信手段，它把被调用者称为服务提供者(Provider)，把调用者称为服务消费者（Consumer），并将对象转换为便于网络传输的二进制或文本数据的过程称为序列化（Serialization）
◆ 常见的RPC技术有Cobra、RMI、WebService、JSON-RPC、XML-RPC、Thrift、Protocol Buffer和gRPC等；
◆ 按照调用方式，可分为四种模式：RR（Request-Response）、Oneway（单向调用）、Future（异步）和Callback（回调）；
◼ MQ：N个系统之间互相通信时，利用MQ可以进行系统间解耦，并借助于失败策略、重试等机制完成错误处理；
◆ 点对点模式
◆ 发布订阅模式

7、传统分布式中间件ESB

早期的SOA系统的服务间通信多采用“点对点”模型，服务调用和集成逻辑也通常嵌入到了应用程序中实现
◼ 适合服务数量较少的系统，简单、高效
◼ 服务数量增多到一定程度时，连接路径和复杂度急剧增加，为应对这种治理挑战而引入了ESB
ESB提供服务间的连接、转换和中介功能
◼ 将企业内部系统和各种服务连接到服务总线上，实现信息系统之间的松耦合架构
◼ 简化了系统集成，使 IT 系统架构更加灵活，并降低了企业内部信息共享的成本

8、ESB的局限性

从技术上讲，ESB 架构将业务逻辑与服务集成分离，从而实现更好的集中式服务治理，但随着应用规模的增大和服务数量的增加，也暴露了严重的问题
◼ 强调甚至过分强调业务系统的可重用性，结果导致大量的服务集成实现逻辑沉入了ESB，很难维护、迁移和扩展，进而成为ESB的沉重负担
◼ 基于集中式消息处理系统，主要挑战是单体架构以及业务逻辑和平台之间紧密的技术耦合，这反而又导致了技术和组织的中心化
◼ 开发并部署服务到这样的系统中时，它和分布性系统框架产生的紧密耦合，限制了服务的进一步演化
◼ 智能管道和哑端点的ESB系统架构无法适应快速变化和大规模创新

9、分布式微服务架构MSA

随着互联网的快速大规模增长，企业IT架构的重点从传统的记录系统转变为参与系统，这类的参与系统必须支持快速迭代和低成本试错，
因而“微服务”的概念甫一出现便甚得人心
◼ 记录系统的代表：企业资源规划ERP和供应链管理SCM等
◼ 参与系统的代表：在线电商系统、网上银行系统等
微服务的规范定义
◼ 最早出现于2011年的“微服务”，2014年由Martin Fowler一篇文章发扬光大，包含以下几个关键点
◆ 由一些独立的服务共同组成应用系统
◆ 每个服务单独部署、独立运行在自己的进程中
◆ 每个服务都是独立的业务
◆ 分布式管理
◼ 遵循低耦合、高内聚的原则
微服务中的调用链路较之传统的分布式系统长了很多，于链路上发生故障的概率也必然随之增大，且存在性能损耗，
于是，系统规划时必须考虑如何进行雪崩预防、功能降级、超时、重试、熔断、服务隔离等服务管理；

10、分布式微服务架构MSA（2）

微服务强调的基本原则
◼ 核心思想是通过应用功能的拆分和解耦来简化业务系统的实现
◼ 强调将应用功能划分为一组松散耦合的服务，每个服务都遵循单一职责原则
◼ 每个服务都可以独立部署和交付，极大地提高了业务敏捷性
◼ 每个服务都可以独立伸缩，以适应互联网的规模
潜在的问题
◼ 将一个大的单一应用拆分成多个微服务，使得IT系统的研发协作、交付和维护变得更加复杂
◼ 幸运的是，容器技术、DevOps和微服务架构的自然融合，使得微服务落地成为更加简便的实现可能
SOA向MSA进化的代表产品
◼ Apache Dubbo
◼ Spring Cloud

11、微服务实践细节

微服务落地过程中，必须要仔细解决如下问题：
◼ 客户端如何访问这些服务？
◆ 各服务的实现上可能是无状态的，因而需要统一进行用户的登录信息和权限管理（OAuth&