微服务架构起源简介及设计PPT推荐.pptx

微服务架构起源简介及设计PPT推荐.pptx

《微服务架构起源简介及设计PPT推荐.pptx》由会员分享，可在线阅读，更多相关《微服务架构起源简介及设计PPT推荐.pptx（49页珍藏版）》请在冰豆网上搜索。

企业架构方法有很多，但TOGAF是最主流的。

TOGAF产出物产出物TOGAF产出物产出物微服务架构起源微服务架构起源-企业转型企业转型传统企业的IT建设需要转型，需要面向外部客户，需要应对外部环境的快速变化、需要快速创新，IT架构也需要向互联网企业学习作出相应的改进，来支撑企业的数字化转型。

先是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是SOA，解决应用系统之间如何集成和互通，微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。

微服务架构起源微服务架构起源-问题问题微服务起源微服务起源-愿景象更换零件一样更换软件微服务架构起源微服务架构起源-技术基础技术基础微服务是在应用技术栈范畴，跟其他的应用技术一样都是具有系统分析、建模的能力，并不是一个纯粹的框架或技术，而是一个综合性的架构模式。

微服务是进化出来的。

“解释一个概念需要用另外几个概念来解释，但是解释另外几个概念还需要其他概念来解释”，所以要聚焦领域，每个领域都是深不见底，都有他的知识体系，都有他的技术栈。

微服务架构起源微服务架构起源-技术基础技术基础技术具体讲就是分析、设计、建模，落地实施方法。

包括几个重量级的技术体系：

TOGAF企业信息架构框架DDD领域驱动设计SOA面向服务架构GRASP通用软件职责设计模式彩色建模四色原型模式GRASP主要是辅助职责设计，四色原型主要是捕捉实体的事件发生序列，不会让你丢失关键业务场景。

微服务与微服务与DDD英文名字：

DomainDrivenDesign。

中文名字：

领域驱动设计。

概述：

DDD是一种以领域为核心的设计和开发理念。

DDD通过维护一个深度反应领域概念的模型，以及提供了可行的经过实践检验的大量模式来应对领域的复杂性，偏向代码实现的（领域）对象微服务与微服务与DDD领域模型既不是脱离代码实现的纯粹业务对象描述，更不是一一对应代码里的表或者对象。

注意以下几点：

1.领域模型是精简的业务知识，所有权是业务代表而不是技术代表2.领域模型的目的是构建业务需求和技术实现之间的桥梁，和传统的buttom-up软件开发模式相比，是一种up-buttom自上而下的开发模式，可以避免需求偏离，因为一开始就是从业务需求出发去构建模型，再参照模型去实现。

3.领域模型是用来解构业务真实需求，可以理解成认识业务的一种方法论，领域模型的作用是构建一种共同语言，业务代表和技术代表在模型上沟通。

4.领域模型是不断迭代进化的，随需求迭代，业务变更而不断演进。

5.好的领域模型可以直接反应软件是做什么用的。

DDD是一种软件开发模式，目的是为了解构复杂的业务需求，降低不同工种间的沟通障碍，实现结构清晰、可复用、易维护的软件。

微服务与微服务与GRASPGRASP是GeneralResponsibilityAssignmentSoftwarePatterns（通用职责分配软件模式）的简称，它的核心思想“职责分配”。

GRASP的主要特征：

对象职责分配的基本原则。

主要应用在分析和建模上。

GRASP的核心思想：

自己干自己的事（职责的分配）自己干自己的能干的事（职责的分配）自己只干自己的事（职责的内聚）如何把现实世界的业务功能抽象成对象，如何决定一个系统有多少对象，每个对象都包括什么职责，GRASP模式给出了最基本的指导原则。

微服务与微服务与GRASP基本原则微服务与微服务与RUP微服务与彩色建模微服务与彩色建模PeterCoad认为，领域模型由以下组成：

v粉红：

代表“瞬间事件”（Moment-Inteval）v黄色：

代表“角色”（Role）v绿色：

代表“人-物-地点”（Party-Place-Thing）v蓝色：

代表“描述”（Description）微服务与微服务与SOASOA产生的背景：

IT建设以部门级为主，业务流程与数据局限于部门内部竖井应用：

不同应用、不同厂商，会形成不同的数据结构、不同的实现从关注部门需求到关注企业需求，需要部门间数据共享/业务共享/客户共享组织与业务流程频繁变化SOA解决的问题：

信息孤岛互联互通业务重用微服务与微服务与SOASOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

SOA可以看作是B/S模型、XML/WebService技术之后的自然延伸。

SOA将能够帮助软件工程师们站在新的高度理解企业级架构中的各种组件的开发、部署形式SOA帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。

SOA能够更加从容地面对业务的急剧变化。

微服务与微服务与SOASOA和微服务的区别：

u微服务不再强调传统SOA架构里面比较重的ESB企业服务总线uSOA的思想进入到单个业务系统内部实现真正的组件化SOA和微服务的共同点：

u服务化u敏捷快速VS微服务与微服务与SOA框架区别框架区别微服务架构定义微服务架构定义微服务架构内涵微服务架构内涵微服务架构内涵微服务架构内涵微服务架构内涵微服务架构内涵微服务架构内涵微服务架构内涵微服务架构好处微服务架构好处是每个微服务组件都是简单灵活的，能够独立部署。

应用不需要一个庞大的应用服务器来支撑。

可以由一个小团队负责更专注专业，相应的也就更高效可靠。

微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。

微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

微服务架构示例微服务架构示例微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务应用设计原则微服务平台微服务平台-企业企业IT基础基础DevOps：

负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。

个人基础环境：

即微服务应用平台，他的目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。

IT基础设施：

各种运行环境支撑如IaaS（VM虚拟化）和CaaS（容器虚拟化）等实现方式。

微服务应用平台目标微服务应用平台目标微服务平台的主要目标主要就是要支撑微服务应用的全生命周期管理，从需求到设计开发测试，运行期的业务数据处理和应用的管理监控等。

微服务应用平台总体架构微服务应用平台总体架构开发集成：

微服务平台需要具备的一些工具和仓库运行时：

微服务平台的基础能力和分布式的支撑能力，微服务运行容器运行在这个平台之上。

监控治理：

对受管的微服务进行统一的监控、配置等能力。

服务网关：

负责与前端的WEB应用移动APP等渠道集成，对前端请求进行认真鉴权，然后路由转发。

微服务应用平台运行架构微服务应用平台运行架构微服务带来的问题微服务带来的问题关键问题关键问题-服务注册和路由服务注册和路由服务在启动的时候，会将自己要发布的服务注册到服务注册中心，运行时，如果需要调用其他微服务的接口，本地缓存或到注册中心获取服务提供者的地址，获得地址后，通过微服务容器内部的负载均衡进行路由调用。

关键问题关键问题-安全认证安全认证安全认证方面，可以基于SpringSecurity结合Auth2再加上JWT（Jsonwebtoken）做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。

认证鉴权一定是个公共服务，而不是多个系统各自建设。

关键问题关键问题-集中配置集中配置配置文件主要有静态配置和动态配置两种。

静态配置通常是在编译部署包之前设置好。

动态配置则是系统运行过程中需要调整的系统变量或者业务参数。

通过制定规范控制配置与介质分离，配置不要放在Jar包里。

配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架需要有个配置中心来统一管理业务系统中的配置信息。

关键问题关键问题-分布式事务微服务架构的系统下，进程成倍增多，分布式事务一致性的问题更加明显。

微服务之间是独立的、调用协议也是无状态的，要解决的是一定时间后的数据达到最终一致状态，一般采用传统的业务补偿与冲正方式。

可靠事件模式：

即事件的发送和接收保障高可靠性，来实现事务的一致性。

补偿模式：

ConfirmCancel，如果确认失败，则全部逆序取消。

TCC模式：

TryConfirmCancel，补偿模式的一种特殊实现通常转账类交易会采用这种模式。

关键问题关键问题-同步调用同步调用微服务架构下，相对于传统部署方式，存在更多的分布式调用，“如何在不确定的环境中交付确定的服务”，可以理解为，我所依赖的服务的可靠性是无法保证的情况下，我如何保证自己能够正常的提供服务，不被我依赖的其他服务拖垮？

关键问题关键问题-同步调用同步调用SEDA:

stagedevent-drivenarchitecture本质上就是采用分布式事件驱动的模式，用异步模拟来同步，无阻塞等待，再加上资源分配隔离结起来的一个解决方案。

微服务相关技术微服务相关技术-dubboDubbo（开源分布式服务框架），阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，主要核心部件：

Remoting:

网络通信框架，实现了sync-over-async和Logorequest-response消息机制.RPC:

一个远程过程调用的抽象，支持负载均衡、容灾和集群功能Registry:

服务目录框架用于服务的注册和服务事件发布和订阅微服务相关技术微服务相关技术-SpringCloudSpringCloud是一系列框架的有序集合：

利用SpringBoot的开发便利性，简化了分布式系统基础设施的开发。

SpringCloudEureka是SpringCloudNetflix的一部分，它基于NetflixEureka做了二次封装，完成微服务架构中的服务治理功能SpringCloudNetflix是对Netflix分布式服务开发框架的封装，包括服务发现和注册、负载均衡、断路器、REST客户端、请求路由等SpringCloudZookeeper对Zookeeper的封装，使之能配合其它SpringCloud项目使用，一般当作注册中心SpringCloudBus分布式消息队列，是对KafkaMQ的封装，实现可靠消息SpringCloudConfig将配置信息中央化保存SpringCloudSecurity对SpringSecurity的封装，实现服务安全等微服务相关技术微服务相关技术-dockerDocker是一个开源的应用容器引擎，让开发者可以打包他们的应用