1、基于Spring Cloud和Netflix的微服务技术架构基于Spring Cloud和Netflix打造Agenda 谈谈微服务 微服务技术选型过程 微服务架构设计的一些思考点 融数微服务架构的核心概念和实现 融数DevOps平台对微服务的支撑 技术团队的组织 Operation ExcellentAgenda 谈谈微服务谈谈微服务 微服务技术选型过程 微服务架构设计的一些思考点 融数微服务架构的核心概念和实现 融数DevOps平台对微服务的支撑 技术团队的组织 Operation Excellent从微服务的概念谈起从微服务的概念谈起高度封装松耦合独立部署独立扩展应用组件微服务与微服务与
2、SOA的异同的异同 从设计原则来讲，微服务架构遵循SOA principles 小的、可重用的服务并不一定是微服务，微服务架构强调敏捷、独立开发、独立部署、独立扩展，重用在某种程度上范围影响 敏捷性 微服务架构为了实现其敏捷特性，在SOA约束的基础之上又添加了新的约束 微服务之间不能互相依赖，因此要求微服务能够独立部署，独立扩展，微服务之间的依赖越少越好 一个应用只做一件事 不要为外部应用发布API，依赖通过service或者事件搞定 最好通过异步事件交互 每个应用拥有自己独立的数据采用微服务需要的一些前提条采用微服务需要的一些前提条件件 没有银弹！微服务将单体应用中的复杂性转移到了应用组件之
3、间 微服务粒度问题：如果粒度太细，就需要一个编排服务，其实退回到了小型的SOA架构 如果服务粒度过粗，就不利于独立部署 采用微服务之前，需要考虑如下几点 微服务架构基础组件：服务路由 服务注册和发现 配置服务 监控 事件溯源（event sourcing）框架团队的敏捷 成熟的如何，是否有足够 的DevOps经 验团队的数据管理方 式是否满足微服务 的要求团队是否有 非常强的架 构实践能力Agenda 谈谈微服务 微服务技术选型过程微服务技术选型过程 微服务架构设计的一些思考点 融数微服务架构的核心概念和实现 融数DevOps平台对微服务的支撑 技术团队的组织 Operation Excell
4、ent微服务技术选型过程微服务技术选型过程 微服务架构技术选型的考虑点社区热度 文档多 坑少 比较容易找到人架构成熟度 方便开发 方便迁移 多协议支持 多语言支持学习曲线 基于成熟技术 现有知识传承可维护性 监控能力 运维能力微服务技术选型过程微服务技术选型过程功能点/服务框架备选方案Netflix/Spring cloudMotangRPCThriftDubbo/DubboX功能定位完整的微服务框架RPC框架,但整合了ZK或Consul,实现集群环境的基本 的服务注册/发现RPC框架RPC框架服务框架支持Rest是Ribbon支持多种可插拔的序列化选 择否否否否支持RPC否是(Hession
5、2)是是是支持多语言是(Rest形式)?否是是否服务注册/发现是(Eureka)Eureka服务注册表，Karyon服务端 框架支持服务自注册和健康检查是(zookeeper/consul)否否是负载均衡是(服务端zuul+客户端Ribbon)Zuul-服务,动态路由云端负载均衡 Eureka(针对中间层 服务器)是(客户端)否否是(客户端)配置服务Netflix ArchaiusSpring cloud Config Server 集中 配置是(zookeeper提供)否否否服务调用链监控是(zuul)Zuul提供边缘服务,API网关否否否否高可用/容错是(服务端Hystrix+客户端Rib
6、bon)是(客户端)否否是(客户端)典型应用案例NetflixSinaGoogleFacebook社区活跃程度高一般高一般已经不维护了学习难度中等低高高低文档丰富度高一般一般一般高其他Spring Cloud Bus为我们的应用程支持降级Netflix内部在开发集成gRPC IDL定义实践的公司比较多微服务技术选型过程微服务技术选型过程目前团队主要采用Spring Boot+RestEasy的方式实现服务化首先支持rest现有业务代码的迁移不希望改动太大小团队，希望能够有一个比较全面的解决方案结论Netflix提供了比较全面的解决方案Spring Cloud对于Netflix的封装比较全面Sp
7、ring Cloud基于Spring Boot，团队有基础Spring Cloud提供了Control Bus能够帮助实现监控埋点业务应用部署在阿里云，Spring Cloud对12factors以及Cloud-Native的支持，有利于在云环境下使用Agenda 谈谈微服务 微服务技术选型过程 微服务架构设计的一些思考点微服务架构设计的一些思考点 融数微服务架构的核心概念和实现 融数DevOps平台对微服务的支撑 技术团队的组织 Operation Excellent微服务架构设计的一些思考微服务架构设计的一些思考点点简化开发调用方便高性能可用性和安 全 方便使用，节约时间 代码生成 Mig
8、ration tools 胶水 方便测试 clients explorer 文档 柔性设计多协议支持，方便 新协议添加CachingContinuations metrics throttling load shedding authenticationAgenda 谈谈微服务 微服务技术选型过程 微服务架构设计的一些思考点 融数微服务架构的核心概念和实融数微服务架构的核心概念和实现现 融数DevOps平台对微服务的支撑 技术团队的组织 Operation Excellent核心模核心模型型 Envelopeconsum erp rod ucer核心模核心模型型Envelope e=;/Ope
9、n EnvelopeCustomer customer=e.get(Customer.class);ProducerCustomer customer=;/Seal in envelopeEnvelope e=factory.newEnvelope();e.set(Customer.class,customer);ConsumerEnvelope APIpublic interface Envelope extends Serializable public void set(Class clazz,T o);public void set(T o);public T get(Class cl
10、azz);public T get();核心模核心模型型 Shapes（定义数据类型（定义数据类型）Simple List Map Structure核心模核心模型型 Traits（定义（定义Shaps的行为的行为）patterntarget=“location”regexvalue=“0-95(?:-0-94)?”/stringname=“location”/核心模核心模型型S S h h apap e eTraitsTraits/E E n n velovelo p p e e1*1*1S S h h apap e eS S imim p p leleC C o o m m p p lex
11、lexS S erviceerviceTraitsTraitsIdId emem p p o o tenten t t TraitsTraitsE E xcepxcep tiotio n n TraitsTraitsF F auau lt lt TraitsTraitsJava Java TraitsTraitsE E n n u u m m TraitsTraitsS S erviceerviceO O p p eratioeratio n n1*InIn p p u u t tO O u u tptp u u t tE E rrorro rsrs1*0.10.1服务处理实服务处理实现现Ha
12、ndlersOrchestratorActivityEndpointClientActivityTransportProtocol插件式插件式EndPointNettyJettyAMPOrchestratorTomcatActivityEndpointClientHTTP/RPCONE WAYOrchestrator重用重用HandlersOrchestratorTransportProtocolHandlersOrchestratorEndpointINTERNETProtocolTransport集成测集成测试试HandlersOrchestratorClient InterfaceMoc
13、k TransportProtocolHandlersOrchestratorMock EndpointActivityProtocolTransport服务处理责任服务处理责任链链Business Logic编写并配置服编写并配置服务务Spring Cloud遵循12 Factors模式Configuration ManagementService discoveryCircuit breakersIntelligent routingControl busOne-time tokensGlobal locksLeadership electionDistributed sessions配置
14、管配置管理理配置信息统一管理提供RESTfulAPI配置信息允许动态变更支持多种数据类型的配置内容分级配置将配置分为多个层级：全局、系统、应用、阶段最终的配置集合，是所有层级的配置的并集同名的配置，末端会覆盖上层的配置（可配置）版本控制配置项和配置集合具有版本信息，发生变更后会保留历史记录配置集合可以随时回退到历史版本配置变更主动通知客户端订阅配置变更信息，在配置发生变更后会立即收到通知和新的配置集合客户端与应用程序集成集成spring-boot提供接口，允许在运行期间动态获取配置本地存储在客户端本地保存当前配置，保证应用程序在不能访问Repository下也可以运行充分抽象，允许多实现配置信
15、息可以保存在数据库里，也可以保存在NoSQL里Repository可以使用Zookeeper或Redis等，也可以自行编写允许自定义配置信息的序列化方式，默认使用 JDK 的序列化方式ZuulLoad balancerLoad balancerLoad balancerZuulZuulZuulA uth S ervice服务发现服务发现:Eureka ServerEureka client会缓存服Eureka server的注册信Eureka的注册只针对ap服务每隔30秒向Eureka如果在15分钟内有85%Eureka Server之间的数务注册信息；息只存储在内存中；plication级别
16、，不支持更细粒度的服务注册，比如单个rest；Server发送心跳，不建议修改心跳时间，Eureka用这个时间来判断集群内是否出现大范围通信异常；的服务没有被续约，则Eureka Server停止移除已注册的服务，以保护已经注册的服务信息不丢失；据同步，采用全量拉取，增量同步的方式Zookeeper CPEtcd CP，DNSEureka-APRibbonLoad B alancerLoad balancerLoad balancerLoad balancer，策略名策略描述实现说明BestAvailableRule选择一个最小的并发请求的server逐个考察Server，如果Server被t
17、ripped了，则忽略，在选择其中ActiveRequestsCount最小的server。AvailabilityFilteringRule过滤掉那些因为一直连接失败的被标 记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈 值）使用一个AvailabilityPredicate来包含过滤server的 逻辑，其实就就是检查status里记录的各个server的 运行状态WeightedResponseTimeRule根据响应时间分配一个weight，响应 时间越长，weight越小，被选中的可 能
18、性越低。一个后台线程定期的从status里面读取评价响应时间 为每个server计算一个weight。当刚开始运行，没有 形成statas时，使用roubine策略选择server。Retry Rule对选定的负载均衡策略机上重试机制。在一个配置时间段内当选择server不成功，则一直尝 试使用subRule的方式选择一个可用的server使用举例：IRule rule=new RetryRule(new RoundRobinRul e(),200);200表示retry的时间间隔RoundRobinRuleroundRobin方式轮询选择server轮询index，选择index对应位置的s
19、erverRandomRule随机选择一个server在index上随机，选择index对应位置的serverZoneAvoidanceRule复合判断server所在区域的性能和server的可用性选择server使用ZoneAvoidancePredicate和 AvailabilityPredicate来判断是否选择某个server，前一个判断判定一个zone的运行性能是否可用，剔 除不可用的zone（的所有server），AvailabilityPredicate用于过滤掉连接数过多的Server。扩 展 点：自 定 义 负 载 均 衡 策 略：ribbon.client.namemy
20、client myclient.ribbon.NFLoadBalancerClassName=均衡器类名myclient.ribbon.NFLoadBalancerRuleClassName=均衡策略类名熔断器：熔断器：HystrixHystrix核心由RxJava驱动，是一个基于观察者模式的事件回调库；Hyxtrix的核心处理逻辑是将调用包装成Command，将对依赖的调用转换成Command API调用；circuitBreaker.allowRequest()判定熔断是否开启;Hystrix熔断器本质是一组状态机，是fast-fail设计思想的体现;处理请求时判定熔断器是否开启，开启使用
21、备选方案(如定义的fallback方法)往下执行，未开启按正常逻辑执行;熔断器依赖metrics收集的health指标，对错误请求数及错误百分 比进行条件判定。circuit-b reaker op en?room in thread p ool?run()successshort-circuitedthread p ool rejectedsuccessfailuretim eoutfal lb ack im p lem ented?fal lb ack sem ap hore at cap acity?getFal lb ack()succeed s?short-circuitedthre
22、ad p ool rejectedsuccessfailureNNNNNNYYYYYYHystrix UI&TurbineNetflix通过turbine聚合Hystrix的监控流信息Hystirx的dashboard监控信息只支持实时监控Netflix内部会把收集到的数据写入到Atlas系统，我们通过Kafka+ELK收集和存储服务端治服务端治理理LBZuulA uth S erviceAAuut ht h S Seer vr vi ci ceeA uth S erviceQ Au eurtyh S erviceC om m and AAuSuteht hr vS Siecerevr vi
23、ci ceeEureka ServerClientsVirtual IP/H ostnam eb indLBZuulb indAgenda 谈谈微服务 微服务技术选型过程 微服务架构设计的一些思考点 融数微服务架构的核心概念和实现 融数融数DevOps平台对微服务的支平台对微服务的支撑撑 技术团队的组织 Operation Excellent部署概念的抽部署概念的抽象象S ervice*1*1包是部署最小单位服务组件由包、配置组成环境包含服务组件以及运行它所依赖的Host或者Host Group有版本才能回滚服务的部服务的部署署服务组件=（可运行代码+配置）&（依赖+配置）&（基础设施+配置）
24、V M/D ocker)S ervice*1*1V M/D ocker)V M/D ocker)DevOps总体架构总体架构GitLibp ul lingnoti fyp ul lingb ind vipnoti f yAgenda 谈谈微服务 微服务技术选型过程 微服务架构设计的一些思考点 融数微服务架构的核心概念和实现 融数DevOps平台对微服务的支撑 技术团队的组织技术团队的组织 Operation Excellent技术团队组织技术团队组织 小团队小团队康威定律Two-Pizza Team 团队成员以7+/-2人为最佳，团队成员水平相当 保持团队规模在个位数，如果超过，拆分团队魔数
25、团队成员能够近距离的沟通，增进彼此的了解干杯规则 团队成员能够非常清楚的了解团队的目标以及其他团队成员的工作团队信息透明化 鼓励创新和自治，团队自己决定使用的技术，鼓励团队间的技术竞争 胜出的团队的方案会被基础架构部门采纳并全公司推广去中心化技术团队组织 团队划分技术团队组织 团队间合作技术团队组织技术团队组织 结果导向结果导向主人翁意识（Ownership）行动力（Bias for Action）吃自己的狗粮（Eat your dog food）工程师负责从需求调研、设计、开发、测试、部署、维护、监控、功能升级等一系列的工作，也就是说 软件工程师负责应用或者服务的全生命周期的所有工作运维是团
26、队成员的第一要务，在强大的自动化运维工具的支撑下，软件工程师必须负责服务或者应用的 SLA让开发人员参与架构设计，而不是架构师参与开发Agenda 谈谈微服务 微服务技术选型过程 微服务架构设计的一些思考点 融数微服务架构的核心概念和实现 融数DevOps平台对微服务的支撑 技术团队的组织 Operation Excellent传统的运维流程传统的运维流传统的运维流程程如何定位问题如何定位人员时效性监控自动化问题反馈一旦发现问题，我们希望能够迅速定位 并安排相应的业务和开发人员及时跟进，直到问题解决新的运维机新的运维机制制C TIC TIR esolve G roupO nC al l*1Operation Excellent/业务驱动改进研发经理监控Sev1&Sev2每周分析COE谢谢谢谢！
