微服务选型与探讨课件

微服务选型与探讨微服务选型与探讨问题汇总1.为什么微服务部署很少采用边缘方式CI?2.宏观角度下微服务架构所适用的场景及运维？3.金融行业的微服务的标准如何制定比较合理？4..netcore微服务需要用到哪些技术？5..netcore微服务有哪些成功的案例？6、微服务与系统模块化的取舍？微服务选型与探讨为什么选择微服务微服务选型与探讨S/N对比点微服务架构单体架构结论1上手难度API接口调用数据库共享或本地程序调用单体架构胜2.1开发效率（简单项目）早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大早期工作量小，随着项目规模和时间的推移，效率大幅度下降单体架构胜2.2开发效率（复杂项目）早期设计和沟通的工作量加大，随着项目规模和时间的推移，效率变化不大早期工作量小，随着项目规模和时间的推移，效率大幅度下降微服务架构胜3系统设计（高内聚低耦合）每个业务单独包装成一个微服务，数据和代码都从物理上隔离开来，实现高内聚低耦合相对容易以包的形式对代码进行模块划分，控制得当即可实现高内聚。但最终都是在数据层面将整个系统耦合在一起微服务架构胜4系统设计（扩展性）独立开发新模块，通过API与现有模块交互在现有系统上修改，与现存业务逻辑高度耦合微服务架构胜5需求变更响应速度各个微服务组件独立变更，容易实施敏捷开发方法需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败微服务架构胜6系统升级效率各个微服务组件独立升级，上手和开发效率高，影响面小需要了解整个系统才可以正确修改，容易导致不相关模块的意外失败微服务架构胜7运维效率大系统被拆分为多个小系统，部署和运维难度加大，但可以利用DevOps等方式将运维工作自动化简单直接单体架构胜8知识积累微服务组件可以在新项目中直接复用，包括前端页面一般以共享库的形式复用后台代码微服务架构胜9.1硬件需求（简单项目）一个系统需部署多个微服务，需要启动多个运行容器整个系统只需要一个运行容器单体架构胜9.2硬件需求（高要求项目）按需为不同业务模块伸缩资源节点为整个系统分配资源，导致冗余微服务架构胜10.1项目成本（简单系统）项目早期和后期，成本变化曲线平缓项目早期成本低，后期成本大单体架构胜10.2项目成本（复杂系统）项目早期和后期，成本变化曲线平缓项目早期成本低，后期成本大微服务架构胜11非功能需求为单独的微服务按需调优，甚至更换实现方式和程序语言为整个系统调优，牵一发而动全身微服务架构胜12职责、成就感拥有明确的职责划分，主人翁意识和成就感加强，容易形成自组织型团队职责不明确，容易产生扯皮行为微服务架构胜13风险大系统被拆分为小系统，风险可被控制在小系统内，但也引入了各小系统之间的交互风险系统是一个整体，一荣俱荣，一损俱损微服务架构胜微服务架构与单体架构的对比微服务选型与探讨康威定律Organizationswhichdesignsystemsareconstrainedtoproducedesignswhicharecopiesofthecommunicationstructuresoftheseorganizations.-MelvinConway(1967)设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构分布式服务组成的系统按照业务而不是技术来划分组织做有生命的产品而不是项目Smartendpoints和dumbpipes（强服务个体和弱通信）自动化运维（DevOps）容错快速演化微服务选型与探讨AKF可扩展立方（ScalabilityCube）X轴扩展——关注水平的数据和服务克隆，也就是前文提到的“加机器解决问题”Y轴扩展——关注应用中职责的划分，比如数据类型，交易执行类型的划分Z轴扩展——关注服务和数据的优先级划分，如分地域划分整个扩展模型，用下图来表示，其中原点代表完全无扩展的状态微服务选型与探讨身份认证用户、客户端、资源交互过程中的身份认证授权框架服务注册服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。服务发现服务调用方从服务注册中心找到自己需要调用的服务的地址。负载均衡服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。服务网关服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。配置中心将本地化的配置信息（properties,xml,yaml等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。API管理以方便的形式编写及更新API文档，并以方便的形式供调用者查看和测试。集成框架微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。分布式事务对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。调用链记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。支撑平台系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过Docker等工具来中和这些微服务架构带来的弊端。例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。常见的微服务组件及概念微服务选型与探讨.NET微服务和容器指南eBookaka.ms/MicroservicesEbook

Referenceapplicationaka.ms/MicroservicesArchitecture覆盖下列主题：领域驱动设计模式领域模型

(Aggregates,Entity,VO,etc.)简单的

CQRSDapperMicroORMforqueriesCommandsandMediatorpatter领域事件(在同一个微服务内)微服务IntegrationEvents(跨多个微服务)Multi-containerdocker-compose.ymlSwaggerw/SwashbuckleSecurity(Authentication/Authorization)withtokensfromIdentityServer4wrappingASP.NETIdentity微服务选型与探讨微服务微服务选型与探讨NewpatternsandnewtechnologiesMicroservicesDockerContainersDockerImageDockerRegistryDockerHubAzureContainerRegistryBoundedContextAPIGatewayEventBusCommandsEventsDockerHostAzureContainerServiceAzureServiceFabricKubernetesDockerSwarmMesosDC/OSLinuxContainersWindowsContainersDomainEventsMediatorAggregatesDomainEntityCQRSsimplifiedDomain-DrivenDesignMessageBrokersRabbitMQAzureServiceBusNServiceBusMassTransitHyper-VContainersAsync.communicationBrighterStatefulServicesActorsOrchestratorsAutonomousDecoupledIsolatedServiceDiscoveryTransientFailuresHandlingResiliencyHealthChecksRetrieswithExponentialBackoffCircuitBreakersPollyNomad&addressableservices微服务选型与探讨Microservices!=Containers但是他们天生一对…

微服务选型与探讨单体应用程序微服务应用程序微服务应用程序把功能分割为更小粒度的服务.通过独立部署各个服务的方式扩展，每个服务可以独立进行扩展单体应用程序在一个进程中运行所有的功能.通过部署应用程序的多个实例进行扩展App1App2App1Fine-graineddensityofservicesCoarse-graineddensityofapps/servicesNeedtodeploythefullapplicationIndependentdeploymentofmicroservice微服务选型与探讨eShopOnContainers参考应用程序-架构OrderingmicroserviceCatalogmicroserviceeShopWebAppMVCASP.NETCoreMVCIdentitymicroservice(STS+users)eShopSPAWebappTypeScript/Angular4eShopmobileappXamarin.FormsC#xPlat.OS:iOSAndroidWindowsDockerHosteShoptraditionalWebappHTMLSQLServerdbClientappsBasketmicroserviceRediscacheMarketingmicroserviceMongoDB/CosmosDBSQLServerDBSQLServerdbSQLServerdbLocationmicroserviceMongoDB/CosmosDBOrdering.APIGracePeriodworkerSvc.微服务选型与探讨微服务模式架构设计微服务选型与探讨微服务关键模式直接访问vs.APIGateway

服务健康检查

弹性云应用程序:

指数退避和

Circuitbreaker进行重试

异步.发布/订阅

(EventBus)

使用协调器进行扩展微服务选型与探讨HealthChecksAPIHealthChecksWatchDogapp/healthMicroservice2Microservice1/health微服务选型与探讨HealthChecksAPIConsumerAConsumerBRouterAPIGatewayServiceRegistryquery/health/healthMicroservice2Microservice1UsuallyProvidedbytheOrchestrator(i.e.ServiceFabric,Kubernetes,etc.)微服务选型与探讨Microservice2Microservice1ClientWebAppMVCContainerContainerWebAPIWebAPIASP.NETCoreMVCContainerMicroservice3ContainerWebAPIClientSPAWebAppJavaScript/Angular.jsClientMobileAppAPIGatewayASP.NETCoreWebAPIContainerBackendTraditionalWebAppBrowserHTMLHTMLJSONJSONBuildingresilientcloudapplicationsHTTPRequest/ResponseHTTPRequest/ResponseImplementresilientcommunicationImplementresilientcommunicationWithRetriesw/exponentialbackoff&Circuit-Breakers微服务选型与探讨Microservice2Microservice1ClientWebAppMVCWebAPIWebAPIASP.NETCoreMVCContainerMicroservice3WebAPIAPIGatewayASP.NETCoreWebAPIBackendRetrieswithExponentialBackoffHTTPRequest/ResponseHTTPRetry1Retry2Retry3Success!微服务选型与探讨Microservice2Microservice1ClientWebAppMVCWebAPIWebAPIASP.NETCoreMVCContainerMicroservice3WebAPIAPIGatewayASP.NETCoreWebAPIBackendRetrieswithExponentialBackoffHTTPRequest/ResponseHTTPRetry1Retry2Retry3Retry4!OpenCircuit!RespondwithException+CircuitBreaker微服务选型与探讨ComponentsforRetries,Circuit-Breaker,etc.NetflixHystrix微服务选型与探讨MultipleHTTPrequestsBrowserSubmitOrderpageBackend/OrchestratorWebAppMultipleCustomersDependency1Dependency2Dependency3Dependency7Dependency8Dependency4Dependency5局部的失效风险会被Microservices放大HTTPrequest/responsecommunicationDependency6Anti-patterns微服务选型与探讨如何最小化微服务所带来的指数故障熔断器

(例如Polly’spolicies等等.)避免在同一个Http调用链中请求长时间的请求/响应

微服务选型与探讨微服务之间的Synchronousvs.AsynccommunicationClienti.e.MVCapp,APIGateway,etc.Httpsync.requestHttpsync.requestHttpsync.requestHttpsync.requestHttpsync.responseHttpsync.responseHttpsync.responseHttpsync.responseSameHttpRequest/Responsecycle!BasketOrderingCatalogOtherClienti.e.MVCapp,APIGateway,etc.Httpsync.requestHttpsync.responseBasketOrderingCatalogOtherSynchronous

allreq./resp.cycleAsynchronous

Comm.acrossinternalmicroservices(EventBus:i.e.AMPQ)“Asynchronous”

Comm.acrossinternalmicroservices(Polling:Http)Clienti.e.MVCapp,APIGateway,etc.Httpsync.responseBasketOrderingCatalogOtherHttpPollingHttpPollingHttpPollingHttpsync.requestHttpPollingAnti-pattern微服务选型与探讨AsynchronousEvent-DrivencommunicationwithanEventBusDatabaseOrderingMicroserviceBasketMicroserviceDatabaseasCacheServiceServiceUser-ProfileMicroserviceWebAPIServiceDatabaseBackendUserUpdatedevent(PublishAction)EventBus(Publish/SubscribeChannel)UpdateUsercommandUserUpdatedeventBuyerinfo

UserUpdatedeventBuyerinfo

Eventualconsistencyacrossmicroservices’databasedonevent-drivenasynccommunication1324DBupdateEventBusAbstractions/InterfaceEventBusImplementationsRabbitMQAzureServiceBusOther:NServiceBusMassTransitetc.微服务选型与探讨业务部门调用链26RPCAWEBA平台体系RPCBWEBBGolang服务PHP服务OR服务……RestFulAPI业务部门业务部门语言种类繁多微服务体系建设不完善/重复网络抖动，dns不稳定4，7层冗长调用链及资源消耗4,7层调度微服务选型与探讨身份认证架构的演变开发过程中常见的交互浏览器与Web应用程序通信,B/S浏览器与webAPI通信B/S基于浏览器的应用程序与WebAPI通信（有时是独立的，有时代表用户）electronnode-webkitH/S桌面程序程序与WebAPI通信C/S后台Service与webAPI通信S/SWebAPI与WebAPI通信（有时是独立的，有时代表用户）S/S微服务选型与探讨Users用户使用注册的客户端访问资源的人。Clients客户端请求令牌的软件，用于验证用户（请求身份令牌）或访问资源（请求访问令牌）。如：Web应用程序，本地移动或桌面应用程序，SPA，服务器进程等。Resources资源想要使用IdentityServer保护的资源-您的用户的身份数据或API。（每个资源都有一个唯一的名称-客户端使用这个名称来指定他们想要访问的资源。）IdentityData身份令牌用户的标识符，可以包含其他身份数据。AccessToken访问令牌访问API资源的令牌。包含有关客户端和用户的信息（如果存在）。API使用该信息来授权访问其数据。微服务选型与探讨简化沟通方式API网关对所有微服务提供单一的访问点安全性对客户端隐藏了服务发现和服务版本阻止大规模攻击，包括SQL注入，XML解析漏洞和DoS攻击验证token,certificates和其他credentials混合通讯协议API网关翻译并支持不同的通讯协议调用频率，跨域，缓存配置需要额外的配置需要管理路由的配置API网关优/缺点微服务选型与探讨API网关优/缺点微服务选型与探讨ServiceFabric简介微服务选型与探讨集群–用于创建资源池托管和环境抽象–运行你自己的工作负载高可用–检测和处理故障编排–管理要求的状态配置管理后台–升级和健康监控编程模型–微服务应用平台可靠和低延迟–支持有状态的工作负载集成解决方案–所需工具都已经集成久经考验–已经使用大约10年什么是ServiceFabric？微服务选型与探讨自己创建一个PaaS，有点崩溃！滚动升级可用性保证可伸缩架构高密度资源治理打包和部署策略强制执行细粒度版本有状态工作负载主节点选择仲裁MesosKubernetesZookeeperRedisRavenMongoDBYarnFleetHadoopContainers?微服务选型与探讨ServiceFabric为常见问题提供了集成解决方案滚动升级可用性保证可伸缩架构高密度资源治理打包和部署策略强制执行细粒度版本有状态工作负载主节点选择仲裁ServiceFabric微服务选型与探讨AzureOtherCloudsOnPremiseDatacentersLifecycleManagementOrchestrationAutoscalingAlwaysOn

AvailabilityDev&OpsToolingProgrammingModelsAzureServiceFabric：运行在任何地方DevBoxHealth&Monitoring微服务选型与探讨AzureOtherCloudsAzureServiceFabric：运行任何程序GuestExecutables(AnyCode)ReliableServices(Java/C#)ReliableActors(Java/C#)

WebAppsContainers(WindowsContainers&Docker)LifecycleManagementAutoscalingAlwaysOn

AvailabilityDev&OpsToolingProgrammingModelsHealth&MonitoringDevBoxOrchestrationOnPremiseDatacenters微服务选型与探讨Tars介绍Tars是一个支持多语言、内嵌服务治理功能，与Devops能很好协同的微服务框架微服务选型与探讨开发框架的特点02使用RPC调用的方式，使业务能快速开发03高性能的实现04丰富的扩展能力，适应不同的业务场景用户透明的实现，让业务聚焦于逻辑实现01微服务选型与探讨开发框架–用户透明的实现BCAD通过封装让通信、服务治理相关功能由框架完成，让开发者聚焦业务逻辑本身使用以IDL实现的Tars协议，屏蔽对象序列化反序列化细节，客户端与服务端的开发人员都直接面向接口编程。协议底层通信封装，支持tcp/udp，以配置的方式让用户灵活选择，并容易扩展支持其他通信协议如rdma、quick等通信在RPC调用的基础上封装future/promise和协程，用户简易实现异步调用，不用关心异步实现细节，封装统一的配置和日志等接口，透明实现云端配置和日志汇聚编程对常用的服务发现、容错&熔断、负载均衡、过载保护、分布式跟踪等等在框架内置服务治理ABCD微服务选型与探讨开发框架–基于TARS协议的RPC框架实现快速开发部署变更容器DevOpsstructUserInfo{1requireintage;2requirecharsex;3optionalstringcompany;4optionalvector<string>hobby;};interfaceUser{intgetUserInfo(intuid,outUserInfoinfo);};客户端Tars文件接口代码自动生成，实现业务快速开发classUserServant{virtualint32getUserInfo(int32uid,UserInfo&info,taf::TarsCurrentPtrcurrent)=0;};版本兼容性好

高性能

多语言支持便利服务端classUserProxy{intgetUserInfo(intuid,UserInfo&info,…);

promise::Future<…>promise_async_getUserInfo(intuid,…);};微服务选型与探讨开发框架设计–高性能的实现C++01NodeJS05模型：NIO、Reactor异步调用：协程、future/promiseJAVA02PHP04模型：Swoole异步调用：协程模型：NIO、Reactor异步调用：future/promise无锁化实现应用层获取时间c扩展的序列化方式全异步GO03模型：协程池、chan异步调用：协程类slab内存分配避免多协程竞争chan优化Buffer队列减少内存拷贝使用快速模式对象使用扁平化字符串06C#模型：NIO、Reactor异步调用：await/async微服务选型与探讨开发框架设计–性能数据框架TPS(10字节)TPS(128字节)TPS(256字节)TARS(C++)617163390686280637TARS(JAVA)430725384113279531TARS(NODEJS)158888158139157334TARS(GO)596795386024276458TARS(PHP)168745169953168617SpringCloud160114157010156830gRPC(C++）893518613281630测试机型：CPU

：4核/8线程3.30GHz内存：16G网卡：千兆serverclientclientclient部署情况：性能数据：微服务选型与探讨开发框架–扩展能力Tars除了具备业界RPC框架常见的能力之外，还具备适应不同业务场景的扩展能力A协议的解析以插件化方式实现，支持http1/2、ssl、pb，并支持用户自定义协议。BC多协议支持1.提供RPC_Call+注册自定义协议的方式，解决Tars服务访问边界系统的服务。2.框架提供TUP(TarsUni-Protocol)协议，解决边界系统的服务访问Tars服务的问题。与边界系统的对接框架给业务开发开放了网络通信底层连接的上下文，并定制化push相关协议，可实现PUSH能力。消息Push支持单向调用的能力，满足一些并不关注调用返回结果的场景，比如流量、延时、超时等统计信息的采集。单向调用D微服务选型与探讨服务治理–整体思路MetricConflogauthzipkinxxxsvrnodekeepaliveclientregistryxxxsvrnodekeepalivegetRoute(“xxxsvr”);监控统计配置中心日志聚合认证鉴权分布式跟踪…开发框架、Registry、node和基础服务集群协同工作，透明完成服务发现/注册、负载均衡、鉴权、分布式跟踪等服务治理相关工作轮询、hash、权重熔断策略：连续超时或失败次数超过阈值一段时间内超时比率阈值微服务选型与探讨服务治理–自动区域感知Clientlogsvrlogsvrlogsvr:80:80:80registrygetAddr(“logsvr”)返回

IP:Port列表:80和:80node深圳宝安深圳坪山szbaoan127.27.*.*szpingshan10.147.*.*常规的负载均衡方式面对跨地区或者跨机房部署的服务会因为网络原因造成延时增大使用不同服务名来解决该问题时会带来繁重的运维工作通过Registry和开发框架配合实现自动区域感知自动区域感知优势运维简单降低延时减少带宽消耗更强的容灾能力微服务选型与探讨服务治理–Set模型容量分区300W在线AB框架支持下的Set分组ABABAB按服务名分SetA1B1A2B2A3B3ABB:80:80registrygetAddr(“B”)返回