微服务的设计思考 PPT
合集下载
Spring Cloud微服务PPT课件
8
是一个解决微服务架构 实施的综合性解决框架
为什么选择Spring Cloud？
整合了诸多被广泛实践和证 明过的框架作为基础部件
大量的兼容性测试，保证 了更好的稳定性
极高的社区活跃度
9
Spring Cloud简介
10
微服务
02
构建 spring boot
11
传统Spring框架：
1、配置web.xml，加载spring 和spring mvc； 2、配置数据库连接、配置 spring事务； 3、配置加载配置文件的读取， 开启注解； 4、配置日志文件； 5、配置完成之后部署tomcat 调试； …
熔断
27
服务容错处理：Spring Cloud Hystrix
缓存
28
工作流程
29
Dashboard
30
Turbine集群监控
31
声明式服
06
务调用 Spring Cloud Feign
32
声明式服务调用：Spring Cloud Feign
快速入门实例
只需创建一个接口并用注解的 方式来配置它，即可完成对服 务提供的接口绑定
360
京东
Netflix
Apache
Spring cloud
Eureka Consoul
分布 式配 置管 理
Diamond
Disconf Qconf
Archaius
Config
批量 任务
服务 跟踪
ElasticJob
Hydra
Task Azkaban
Sleuth
Zipkin
微服务构建：Spring Boot
互联网金融微服务架构设计ppt课件
对企业来说，SaaS的优点： ⒈ 从技术方面来看：SaaS是简单的部署，不需要购买任何硬件，刚开始只需要简单注册即可。
企业无需再配备IT方面的专业技术人员，同时又能得到最新的技术应用，满足企业对信息管理的 需求。
⒉ 从投资方面来看：企业只以相对低廉的“月费”方式投资，不用一次性投资到位，不占用 过多的营运资金，从而缓解企业资金不足的压力；不用考虑成本折旧问题，并能及时获得最新硬 件平台及最佳解决方案。
互联网技术
PAAS(平台即服务)
PaaS是Platform-as-a-Service的缩写，意思是平台即服务。 把服务器平台作为一种服务 提供的商业模式。通过网络进行程序提供的服务称之为SaaS(Software as a Service)，而云计 算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS(Platform as a Service)。 所谓PaaS实际上是指将软件研发的平台（计世资讯定义为业务基础平台）作为一种服务，以 SaaS的模式提交给用户。因此，PaaS也是SaaS模式的一种应用。但是，PaaS的出现可以加快 SaaS的发展，尤其是加快SaaS应用的开发速度。在2007年国内外SaaS厂商先后推出自己的PAAS 平台。
互联网技术
SOA(面向服务的架构)
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为 服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进 行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在 各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
对于一个SOA解决方案来说就需要能够满足这些场景的业务需求，能够解决其中 的各种技术问题。需要解决的基本问题包括：
企业无需再配备IT方面的专业技术人员，同时又能得到最新的技术应用，满足企业对信息管理的 需求。
⒉ 从投资方面来看：企业只以相对低廉的“月费”方式投资，不用一次性投资到位，不占用 过多的营运资金，从而缓解企业资金不足的压力；不用考虑成本折旧问题，并能及时获得最新硬 件平台及最佳解决方案。
互联网技术
PAAS(平台即服务)
PaaS是Platform-as-a-Service的缩写，意思是平台即服务。 把服务器平台作为一种服务 提供的商业模式。通过网络进行程序提供的服务称之为SaaS(Software as a Service)，而云计 算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS(Platform as a Service)。 所谓PaaS实际上是指将软件研发的平台（计世资讯定义为业务基础平台）作为一种服务，以 SaaS的模式提交给用户。因此，PaaS也是SaaS模式的一种应用。但是，PaaS的出现可以加快 SaaS的发展，尤其是加快SaaS应用的开发速度。在2007年国内外SaaS厂商先后推出自己的PAAS 平台。
互联网技术
SOA(面向服务的架构)
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为 服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进 行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在 各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
对于一个SOA解决方案来说就需要能够满足这些场景的业务需求，能够解决其中 的各种技术问题。需要解决的基本问题包括：
微服务入门ppt课件
Netflix Zuul
Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘 服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网 站后端所有请求的前门。当其它门派来找大哥办事的时候一 定要先经过zuul,看下有没有带刀子什么的给拦截回去，或者 是需要找那个小弟的直接给带过去。
• 作为一个微服务治理的大家伙，考虑的很全面，几乎服务治理的方 方面面都考虑到了，方便开发开箱即用。
• Spring Cloud 活跃度很高，教程很丰富，遇到问题很容易找到解决方 案
• 轻轻松松几行代码就完成了熔断、均衡负责、服务中心的各种平台 功能
与Spring Boot的关系
Spring boot 是 Spring 的一套快速配置脚手架，可以基于 spring boot 快速开发单个微服务，Spring Cloud是一个基于 Spring Boot实现的云应用开发工具；Spring boot专注于快速、 方便集成的单个个体，Spring Cloud是关注全局的服务治理框 架；spring boot使用了默认大于配置的理念，很多集成方案已 经帮你选择好了，能不配置就不配置，Spring Cloud很大的一 部分是基于Spring boot来实现
统瘫痪; • 系统不会被长期限制在某个技术栈上。
微服务不足
• “微服务”强调了服务大小 • 业务逻辑。 • 分区数据库 • 测试
三、微服务架构工作流程
微服务架构工作流程
• 设计阶段 将产品功能拆分为若干服务 为每个服务设计API接口
• 开发阶段 实现API接口（包括单元测试） 开发UI原型（页面）
●主要内容
一、服务架构设计的发展 二、微服务简介 三、微服务架构工作流程 四、springCloud介绍
微服务架构 ppt课件
Microservice
The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
在变得越来越大的同时，我们的应用所使用的技术 也会变得越来越多。这些技术有些是不兼容的，就 比如在一个项目中大范围地混合使用C++和Java几 乎是不可能的事情。在这种情况下，我们就需要抛 弃对某些不兼容技术的使用，而选择一种不是那么 适合的技术来实现特定的功能。
除此之外，由于按照Monolith组织的代码将只产生 一个包含了所有功能的WAR包，因此在对服务的 容量进行扩展的时候，我们只能选择重复地部署这 些WAR包来扩展服务能力，而不是仅仅扩展出现 系统瓶颈的组成
微服务架构原理和设计方法ppt(49张)
微 服 务 架 构 原理和 设计方 法(PPT 49页) 微 服 务 架 构 原理和 设计方 法(PPT 49页)
业务架构：是把企业的业务战略转化为日常 运作的渠道，业务战略决定业务架构，它包括 业务的运营模式、流程体系、组织结构、地域 分布等内容
IT架构：指导IT投资和设计决策的IT框架， 是建立企业信息系统的综合蓝图，包括数据架 构、应用架构和技术架构三部分。
企业架构
TOGAF架构
TOGAF 由国际标准权威组织The Open Group制定。1993年开始应客户要求制定系统 架构的标准，在1995年发表 (TOGAF) 架构框 架。TOGAF的基础是美国国防部的信息管理技 术架构，是基于一个迭代的过程模型，支持最 佳实践和一套可重用的现有架构资产。它可设 计、评估、并建立组织的正确架构。
微 服 务 架 构 原理和 设计方 法(PPT 49页)
微服务与DDD
英文名字：Domain Driven Design。
中文名字：领域驱动设计。
Байду номын сангаас概 述：DDD是一种以领域为核心 的设计和开发理念。DDD通过维护一 个深度反应领域概念的模型，以及提 供了可行的经过实践检验的大量模式 来应对领域的复杂性，偏向代码实现 的（领域）对象
微 服 务 架 构 原理和 设计方 法(PPT 49页)
微 服 务 架 构 原理和 设计方 法(PPT 49页) 微 服 务 架 构 原理和 设计方 法(PPT 49页)
信息专家 创建者 高内聚 低耦合 控制者 多态 纯虚构 间接性
变化预防
微服务与GRASP基本原则
• 给对象分配职责的基本原则是什么？ • 假设系统中存在一个类A，那么在这个系统中，谁应该负责创建类A的新实例？ • 怎样保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？ • 怎样降低依赖性，减少变化带来的影响，提高重用性？ • 在UI层之上首先接收和协调（控制）系统操作的第一个对象是什么？ • 如何处理基于类型的选择？如何创建可插拔的软件构件？ • 当你并不想违背高内聚和低耦合或其他目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责？ • 为了避免两个或多个事务之间直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提高复用性潜力？ • 如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其他元素产生不良影响？
微服务架构 ppt课件
微服务架构
主讲人：xxx 组员：xxx
微服务的诞生 1
2
Monolith
CONTENTS
微服务的定义 3
微服务架构模式 4
微服务架构的优点与缺点 5 具体应用 6
微服务的诞生
微服务架构（Microservice Architect）是 一种架构模式，它提倡将单块架构的应用 划分成一组小的服务，服务之间互相协调、 互相配合，为用户提供最终价值。每个服 务运行在其独立的进程中，服务与服务间 采用轻量级的通信机制互相沟通。每个服 务都围绕着具体业务进行构建，并且能够 被独立的部署到生产环境、类生产环境等。
可以说，所有的不便都是由于Monolith服务中一个 WAR包包含了该服务的所有功能所导致的。而解 决该问题的方法就是Microservice架构模式。
微服务的定义
实际上，从业界的讨论来看,微服务本身 并没有一个严格的定义。不过， ThoughtWorks的首席科学家，马丁 -福 勒先生对微服务的这段描述，似乎更加具 体、贴切，通俗易懂：
但是这种扩展方式极 大地浪费了资源。就 以上图所展示的情况 为例：在一个服务中， 某个组成的负载已经 达到了90%，也就是 到了不得不对服务能 力进行扩容的时候了。 而同一服务的其它三 个组成的负载还没有 到其处理能力的20%。
由于Monolith服务中 的各个组成是打包在 同一个WAR包中的， 因此通过添加一个额 外的服务实例虽然可 以将需要扩容的组成 的负载降低到了45%， 但是也使得其它各组 成的利用率更为低下。
微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序 划分成一组小的服务，服务之间互相协调、互相配合， 为用户提供最终价值。每个服务运行在其独立的进程 中，服务与服务间采用轻量级的通信机制互相沟通 （通常是基于HTTP协议的RESTful API）。每个服务 都围绕着具体业务进行构建，并且能够被独立的部署 到生产环境、类生产环境等。另外，应当尽量避免统 一的、集中式的服务管理机制，对具体的一个服务而 言，应根据业务上下文，选择合适的语言、工具对其 进行构建。
主讲人：xxx 组员：xxx
微服务的诞生 1
2
Monolith
CONTENTS
微服务的定义 3
微服务架构模式 4
微服务架构的优点与缺点 5 具体应用 6
微服务的诞生
微服务架构（Microservice Architect）是 一种架构模式，它提倡将单块架构的应用 划分成一组小的服务，服务之间互相协调、 互相配合，为用户提供最终价值。每个服 务运行在其独立的进程中，服务与服务间 采用轻量级的通信机制互相沟通。每个服 务都围绕着具体业务进行构建，并且能够 被独立的部署到生产环境、类生产环境等。
可以说，所有的不便都是由于Monolith服务中一个 WAR包包含了该服务的所有功能所导致的。而解 决该问题的方法就是Microservice架构模式。
微服务的定义
实际上，从业界的讨论来看,微服务本身 并没有一个严格的定义。不过， ThoughtWorks的首席科学家，马丁 -福 勒先生对微服务的这段描述，似乎更加具 体、贴切，通俗易懂：
但是这种扩展方式极 大地浪费了资源。就 以上图所展示的情况 为例：在一个服务中， 某个组成的负载已经 达到了90%，也就是 到了不得不对服务能 力进行扩容的时候了。 而同一服务的其它三 个组成的负载还没有 到其处理能力的20%。
由于Monolith服务中 的各个组成是打包在 同一个WAR包中的， 因此通过添加一个额 外的服务实例虽然可 以将需要扩容的组成 的负载降低到了45%， 但是也使得其它各组 成的利用率更为低下。
微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序 划分成一组小的服务，服务之间互相协调、互相配合， 为用户提供最终价值。每个服务运行在其独立的进程 中，服务与服务间采用轻量级的通信机制互相沟通 （通常是基于HTTP协议的RESTful API）。每个服务 都围绕着具体业务进行构建，并且能够被独立的部署 到生产环境、类生产环境等。另外，应当尽量避免统 一的、集中式的服务管理机制，对具体的一个服务而 言，应根据业务上下文，选择合适的语言、工具对其 进行构建。
微服务技术架构体系分享ppt课件
当前软件开发行业面临的挑战
有效应对流量洪峰，扩展更加方便便捷，像使用水、电一样按需使用计算资源
业务组件边界变小，调整变更容易，快速适应业务发展变化
进行顶层规划设计，不断积累IT业务组件资产，IT建设总成本下降
微服务云化的好处有哪些
开发团队不受技术限制，可快速应用当前优秀技术体系
拥有IT业务组件资产，快速构建系统响应市场变化，及时把握市场机会
Android学员端
后端
通用服务
前端
ios学员端
Web学员端
Web管理端
APIGateway（zuul）
路由
业务服务
认证服务对练服务系统服务短信服务…营销服务
帐务服务
…
消息总线、 消息总线
服务发现
配置管理
链路跟踪
断路监控
日志收集
性能监控
持续集成
自动化部署
自动化测试
自动化构建
分布式服务架构阶段实施建议：
阶段 一
阶段 二
阶段 三
阶段 四
分布式缓存、
微服务底层运行框架切面
分布式事务
感谢您的观看!
第二部分微服务云化解决方案
PART 02
02
微服务云化技能体系
微服务云化技术解决方案
教务系统分布式服务架构图（简图）
Android学员端
后端
通用服务
前端
ios学员端
Web学员端
Web管理端
APIGateway（zuul）
路由
业务服务
认证服务
对练服务
系统服务
短信服务
…
营销服务
帐务服务
…
消息总线、 消息总线
微服务云化概览
有效应对流量洪峰，扩展更加方便便捷，像使用水、电一样按需使用计算资源
业务组件边界变小，调整变更容易，快速适应业务发展变化
进行顶层规划设计，不断积累IT业务组件资产，IT建设总成本下降
微服务云化的好处有哪些
开发团队不受技术限制，可快速应用当前优秀技术体系
拥有IT业务组件资产，快速构建系统响应市场变化，及时把握市场机会
Android学员端
后端
通用服务
前端
ios学员端
Web学员端
Web管理端
APIGateway（zuul）
路由
业务服务
认证服务对练服务系统服务短信服务…营销服务
帐务服务
…
消息总线、 消息总线
服务发现
配置管理
链路跟踪
断路监控
日志收集
性能监控
持续集成
自动化部署
自动化测试
自动化构建
分布式服务架构阶段实施建议：
阶段 一
阶段 二
阶段 三
阶段 四
分布式缓存、
微服务底层运行框架切面
分布式事务
感谢您的观看!
第二部分微服务云化解决方案
PART 02
02
微服务云化技能体系
微服务云化技术解决方案
教务系统分布式服务架构图（简图）
Android学员端
后端
通用服务
前端
ios学员端
Web学员端
Web管理端
APIGateway（zuul）
路由
业务服务
认证服务
对练服务
系统服务
短信服务
…
营销服务
帐务服务
…
消息总线、 消息总线
微服务云化概览
《微服务入门》课件
优势
Docker容器化技术可以快速部署应用程序，并且 每个容器都是独立的、可移植的、易于管理的。
适用场景
适用于快速部署和运行微服务，以及需要快速迭 代和部署的应用程序。
Kubernetes与容器编排
概述
Kubernetes是一种容器编排系统 ，可以自动化容器的部署、扩展 、管理和升级等操作。
功能
Kubernetes提供了自动容器的部 署、自动容器的伸缩、自动容器 的故障恢复等功能。
核心组件
02
包括服务发现（Eureka）、配置管理（Spring Cloud Config
）、断路器（Hystrix）、路由（Zuul）等。
适用场景
03
适用于构建复杂的分布式系统，尤其适用于快速迭代和快速部
署的需求。
Docker与容器化
概述
Docker是一种容器化技术，通过容器化可以快速 部署和运行应用程序。
《微服务入门》 ppt课件
contents
目录
• 微服务概述 • 微服务架构设计 • 微服务开发技术 • 微服务部署与运维 • 微服务案例与实践 • 总结与展望
01
CATALOGUE
微服务概述
微服务的定义
微服务是一种软件架构风格，它将应 用程序拆分成一系列小的、独立的服 务，每个服务都运行在独立的进程中 ，并使用轻量级通信协议进行通信。
04
CATALOGUE
微服务部署与运维
持续集成与部署
持续集成
通过自动化工具定期构建、测试和合并代码，确保代码质量。
持续部署
自动化部署微服务到生产环境，减少手动干预和错误。
容器化技术
使用Docker等容器技术，实现微服务的快速部署和管理。
Docker容器化技术可以快速部署应用程序，并且 每个容器都是独立的、可移植的、易于管理的。
适用场景
适用于快速部署和运行微服务，以及需要快速迭 代和部署的应用程序。
Kubernetes与容器编排
概述
Kubernetes是一种容器编排系统 ，可以自动化容器的部署、扩展 、管理和升级等操作。
功能
Kubernetes提供了自动容器的部 署、自动容器的伸缩、自动容器 的故障恢复等功能。
核心组件
02
包括服务发现（Eureka）、配置管理（Spring Cloud Config
）、断路器（Hystrix）、路由（Zuul）等。
适用场景
03
适用于构建复杂的分布式系统，尤其适用于快速迭代和快速部
署的需求。
Docker与容器化
概述
Docker是一种容器化技术，通过容器化可以快速 部署和运行应用程序。
《微服务入门》 ppt课件
contents
目录
• 微服务概述 • 微服务架构设计 • 微服务开发技术 • 微服务部署与运维 • 微服务案例与实践 • 总结与展望
01
CATALOGUE
微服务概述
微服务的定义
微服务是一种软件架构风格，它将应 用程序拆分成一系列小的、独立的服 务，每个服务都运行在独立的进程中 ，并使用轻量级通信协议进行通信。
04
CATALOGUE
微服务部署与运维
持续集成与部署
持续集成
通过自动化工具定期构建、测试和合并代码，确保代码质量。
持续部署
自动化部署微服务到生产环境，减少手动干预和错误。
容器化技术
使用Docker等容器技术，实现微服务的快速部署和管理。
SpringCloud微服务精品PPT课件
为什么选择Spring Cloud？
整合了诸多被广泛实践和证 明过的框架作为基础部件
大量的兼容性测试，保证 了更好的稳定性
极高的社区活跃度
Spring Cloud简介
微服务
02
构建 spring boot
传统Spring框架：
1、配置web.xml，加载spring 和spring mvc； 2、配置数据库连接、配置 spring事务； 3、配置加载配置文件的读取， 开启注解； 4、配置日志文件； 5、配置完成之后部署tomcat 调试； …
服务治理：Spring Cloud Eureka
快速入门实例
客户端负
04
载均衡 Spring Cloud Ribbon
客户端负载均衡：Spring Cloud Ribbon
服务端 负载均衡
负载 均衡
硬件负载 均衡(F5)
可用的服 务端清单
软件负载 均衡(Nigix)
可用的服 务端清单
客户端 负载均衡
微服务构建：Spring Boot
快速入门实例
服务
03
治理 Spring Cloud Eureka
服务治理机制
服务注册中心
失效剔除 默认每隔一段时间 （默认60秒）将当 前清单中超时（默 认为90秒）没有续 约的服务剔除出去
自我保护
心跳失败的比例在 15分钟之内低于 85%时，Eureka Server会将当前的 实例注册信息保护 起来，让这些实例 不会过期。
服务容错处理：Spring Cloud Hystrix
资源隔离
服务容错处理：Spring Cloud Hystrix
降级机制
服务容错处理：Spring Cloud Hystrix
整合了诸多被广泛实践和证 明过的框架作为基础部件
大量的兼容性测试，保证 了更好的稳定性
极高的社区活跃度
Spring Cloud简介
微服务
02
构建 spring boot
传统Spring框架：
1、配置web.xml，加载spring 和spring mvc； 2、配置数据库连接、配置 spring事务； 3、配置加载配置文件的读取， 开启注解； 4、配置日志文件； 5、配置完成之后部署tomcat 调试； …
服务治理：Spring Cloud Eureka
快速入门实例
客户端负
04
载均衡 Spring Cloud Ribbon
客户端负载均衡：Spring Cloud Ribbon
服务端 负载均衡
负载 均衡
硬件负载 均衡(F5)
可用的服 务端清单
软件负载 均衡(Nigix)
可用的服 务端清单
客户端 负载均衡
微服务构建：Spring Boot
快速入门实例
服务
03
治理 Spring Cloud Eureka
服务治理机制
服务注册中心
失效剔除 默认每隔一段时间 （默认60秒）将当 前清单中超时（默 认为90秒）没有续 约的服务剔除出去
自我保护
心跳失败的比例在 15分钟之内低于 85%时，Eureka Server会将当前的 实例注册信息保护 起来，让这些实例 不会过期。
服务容错处理：Spring Cloud Hystrix
资源隔离
服务容错处理：Spring Cloud Hystrix
降级机制
服务容错处理：Spring Cloud Hystrix
微服务架构与SpringCloudppt课件
服务C
hystrix系列
• Hystrix 监控和断路器。我们只需 要在服务接口上添加Hystrix标签， 就可以实现对这个接口的监控和断 路器功能。
• Hystrix Dashboard 监控面板， 他提供了一个界面，可以监控各个 服务上的服务调用所消耗的时间等 。
• Hystrix Turbine 监控聚合，使用 Hystrix监控，我们需要打开每一个 服务实例的监控信息来查看。而 Turbine可以帮助我们把所有的服 务实例的监控信息聚合到一个地方 统一查看。这样就不需要挨个打开 一个个的页面一个个查看。
注册
读取注册服务
服务
心跳 eureka
ribbon
• 负载均衡 Zuul网关将一个请求发 送给某一个服务的应用的时候，如 果一个服务启动了多个实例，就会 通过Ribbon来通过一定的负载均 衡策略来发送给某一个服务实例。
Ribbon 微服务A实例 微服务A实例
feign
• 服务客户端 服务之间如果需要相 互访问，可以使用RestTemplate ，也可以使用Feign客户端访问。 它默认会使用Ribbon来实现负载 均衡。
• Spring Cloud是基于Spring Boot的一整套实现微服务 的框架。
• Spring Cloud Netflix是基于Netflix组件的再次封装， 提升了易用性以及与Spring Cloud其他组件整合性
Spring cloud netflix
Eureka 与 consul
• 服务注册和发现 提供了一个服务 注册中心、服务发现的客户端，还 有一个方便的查看所有注册的服务 的界面。 所有的服务使用Eureka 的服务发现客户端来将自己注册到 Eureka的服务器上。
微服务技术交流ppt课件
Container Engine
Container Microservices
Container Functions
Container Diagnostics
Fully managed container service based on Kubernetes running
on Oracle Cloud Infrastructure Bare
Broker
Copyright © 2017 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
3
客户端的调用
浏览器 UI
产品 服务
Copyright © 2017 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
1
微服务应用 vs. 单体应用 – 微服务应用
浏览器 UI
产品 服务
产品
订单 服务
订单
库存 服务
库存
用户 服务
用户
…… 服务
……
DB
DB
DB
DB
DB
微服务特性
✓ 拆分应用，实现敏捷开发和部署 ✓ 组件化到多服务 ✓ 围绕业务功能组织团队 ✓ 做产品而不是做项目 ✓ 智能端点与傻瓜管道
✓ 去中心化的治理技术 ✓ 去中心化的管理数据 ✓ 基础设施自动化 ✓ 容错设计 ✓ 演进式设计
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– 下单； – 拆单； – 校验； – 支付； –…
– 库存调度 – 物流调度 – 售后服务调度 – ...
– 按用户查询； – 按营业员查询； – 按手机号查询； –…
未来：使用Stratety模式，细分服务！
Agenda
01 微服务的设计
02 微服务的架构模式
03 微服务的的监控
PART TWO 微服务的架构模式
货到付款
融合支付
13.销售方式
14.商品特性 15.发票
16.结算
正常
分账
9.支付次数
一次支付
二次支付
PART ONE 微服务的设计： 服务拆分举例
fi$
1..*
fi$ ¼ fi fi fi fi@fi fi fi
fi
交易订单
履约订单
查询订单
PART ONE 微服务的设计： 服务拆分举例
交易服务 履约服务 查询服务
微服务方式实现新特性
离旧应用，提高扩展性
策
第二步：“扼杀旧应用”
略 不断地提取微服务，直到应用中全部的”限界上下文”都提取为微服务或其中所剩内
容已无必要再提取。
提取组件为服务的标准：通过区分”限界上下文”，形成微服务
标准1：识别整体架构内的”限界上下 文”,把不一致概念的分开。
标准2：处理优先级。在候选功能中，是 否是优先的功能提取？
PART ONE 关键问题（四） ：反模式
PART ONE 微服务的设计： 服务拆分举例
因应业务发展而不断演变！
电商应用
商品
价格
库存 购物车
会员
订单
促销 . ..
会员
电商应用
商品
价格
库存
订单
购物车
促销
. ..
会员
会员
订单应用
拆 ...
由一个商业套件实现 全
部应用功能
历经3-4年
采用SOA模式，整合各定 制 的单一分层应用
订单的场景：
1.来源渠道
线下门店
线上
批发
对公/工程
10.顾客
个人
企业
2.下单终端
11.自营销售 方 式
先销后采
先采后销
3.业态分类
零售
4.业态来源
电器
...
超市
12.线上购物
正常 名品特卖
抢购 海外购
闪拍
5.商品分类
实体商品
虚拟商品
服务商品
6.经营模式
自营
第三方
...
7.配送方式
8.支付方式
在线支付
微服务的设计思考
2017/12
PART ONE
01 微服务的设计
02 微服务的架构模式
03 微服务的的监控
PART ONE 微服务的设计： 概念
一种架构风格、架构模式
松耦合、单一职责、基于限界上 下文的一种SOA的落地实现
服务能够独立构建、独立 部署、独立扩展
微服务
基于Devops，面向运维的架构
PART ONE
微服务的设计
微服务构建的演进
Monolithi c
• 单体应用
• 分层架构
• 多种业务 功能耦合
提高访问性
MacroServic es
• SOA类应用 • 粗粒度 • 共享数据 • 单体部署
提高敏捷性
MiniServic es
• 细粒度 （Domain）
• 独立数据
• 独立部署
提高伸缩性
• 业务需求：
• 接单：近200种场景的接单； • 审核与资源处理：处理会员权益、促销资格、价格、优惠、库存等； • 交易处理：支付相关操作； • 查询：按多维度； • 分发：同步必要的订单信息；
• 技术环境：
• 基于虚机的私有云环境； • 处理单元化（可在分区内完成全部处理），利于跨机房部署；
PART ONE 微服务的设计： 服务拆分举例
Microservices Reference Architecture （By NGINX）
• Proxy作为API网关 与 控制器；
大家应该也有点累了，稍作休息
大家有疑问的，可以询问和交流
PART ONE 关键问题（三）：服务拆到什么程度
微服务的拆解粒度：how small is“small”? •最佳实践：
• 先粗后细：开始拆解时，很难一次性给出合适的粒度，可以先划分的粗些。 • 不断调整：当对服务有了更多认识后，会不断调整粒度，进行服务的进一步拆分、合并。
ቤተ መጻሕፍቲ ባይዱ
• 现有架构下，再怎样加硬件 也无法改善应用指标
•…
业务驱 动力
技术环 境
准备工作
业务需 求
整体组 织架构
PART ONE 关键问题（二）：怎样设计出微服务
单体应用的分解方法： 拆
第一步：构建所有的新加特性作为微服务
不摧毁应用，也不加入新功能，而是使用 集成新的微服务：anti-corruption layer， 隔
需要团队组织、文化的调整和完 善的自动化工具
实施中体现为：受业务驱动，不 断演进的架构
PART ONE 微服务的设计
常见误区： 我使用了Springboot或Dubbo等，所以我使用了微服务 微服务有助于提升应用性能 微服务只是一种新的架构模式，开发中改变下架构与设计方法就 可以做到微服务 我使用了 Docker容器，所以我使用了微服务 或者，我们没上容器，所以没法使用微服务 通过在微服务框架上开发微服务，仍可以保证事务的实现
MicroServic es
• 细粒度 （Feature）
• 独立数据
• 独立部署
PART
关键问题（一） ：该用微服务吗
ONE
• Do right things! 的有需要吗？
业务上真
• 微服务不是“银弹”，并不适 合于每个应用和所有环境；
• 原则：最好不拆！ • 何时采用微服务
• 业务响应速度已受到严重影 响，现有常规办法已无效果
•“类”与“服务”：类的数量不是粒度衡量的标准 • 服务实际上是指服务组件，被认为是承担特定职责的架构组件； • 服务组件怎么实现和用多少类实现，要根据设计情况定；
•确定服务粒度的基准测试 • 服务的范围与功能：分析服务提供的操作的内聚层次，拆分指示词，“并且”、“此外” • 数据库事务：分布式的影响，ACID vs.BASE transactions ，是否服务粒度过细 • 分析服务编织的层次：编织会降低整体性能；影响可用性与健壮性。太多的编织意味着 服务粒度过细。请求响应能力与可靠性间的权衡 • 考虑组织文化、团队规模：Two-pizza Team,Cross
历经2-3年
开始按照限界上下文进行 服务拆分，但粒度较粗
PART ONE 微服务的设计： 服务拆分举例
• 业务驱动力：
• 单体应用性能差，越来越难以通过硬件扩展来提升服务水平 • 难以快速开发、全量回归测试困难、难以快速部署上线，影响公司业务发展； • 希望大幅提升订单的开发效率，易于快速开发、快速测试，降低复杂度；