• 关于

    平台调用服务错误如何解决

    的搜索结果

问题

【精品问答】阿里云开放平台、SDK

问问小秘 2020-04-24 17:27:31 11 浏览量 回答数 1

问题

【精品问答】企业级分布式应用服务 EDAS相关了解

montos 2020-04-08 10:53:03 2 浏览量 回答数 1

问题

阿里云-小程序云

问问小秘 2020-04-07 18:45:54 24 浏览量 回答数 1

阿里云高校特惠,助力学生创业梦!0元体验,快速入门云计算!

学生动手场景应用,快速了解并掌握云服务器的各种新奇玩法!

问题

【精品问答】dubbo常见技术问题集

游客pklijor6gytpx 2019-12-01 21:54:03 31 浏览量 回答数 1

问题

报错is-business-limit-control-message如何解决?

nicenelly 2019-12-01 20:59:25 1436 浏览量 回答数 0

问题

企业级分布式应用服务 EDAS应用场景一般在哪里?

猫饭先生 2019-12-01 21:03:04 1064 浏览量 回答数 0

问题

钉钉开放平台“常见问题常见问题常见问题“重要请关注

竹梅 2019-12-01 21:57:52 74299 浏览量 回答数 28

回答

1、 描述下应用架构的发展历程 目前,架构的发展历程是从单体架构、分布式架构、SOA架构,再到如今流行的微服务架构 2、单体架构的优点、缺点 优点: I 易于开发,开发人员可在短时间内开发完成单体应用 II 易于测试 III 易于部署 缺点: I 灵活程度不够,一旦修改,自上而下需要整体部署,才可以展现出效果,同时开发效率低,降低团队灵活性 II 降低系统的性能 III 系统启动、重启缓慢 IV 扩展性差 3、 什么是传统的分布式架构 简单来说,就是按照业务垂直切分,每个应用都是一个单体架构,通过API接口互相调用 好处是,依赖解耦,理解清晰,开发便捷速度,缺点是调用存在风险,技术复杂,可靠性降低 4、 SOA架构的优点、缺点 面向服务的SOA架构,根据不同的业务建立不同的服务,优点,模块拆分,开发聚合,降低了耦合度,增加功能,增加子项目即可,方便部署,灵活的分布式部署 缺点,调用、交互采用远程通信,接口开发增加工作量 5、 什么是微服务技术 微服务架构在某种程度上是SOA架构的发展。微服务是一种架构风格,对于一个大型的复杂的业务应用系统,业务功能可以拆分为多个独立的微服务,各个服务间是松耦合的,通过各种远程通信协议,实现交互,各个服务可以独立部署、扩容、升降级 6、 目前流行的微服务解决方案 目前最常见的,包括两种,一种基于SpringCloud中间件的微服务解决方案,选型比较中立,内部组件,可以自由更换搭配使用,大致上三种,服务发现,一种Eureka,一种Consul,一种etcd或者阿里nacos,共用组件,服务调用组件Feign。负载均衡ribbon,熔断器hystrix,网关,zuul,gateway,等,配置中心,携程阿波罗,nacos,Config;全链路监控,zipkin,pinpoint,skywalking,其他组件 另一种基于Dubbo实现微服务解决方案,可以Dubbo,nacos,其他 7、 什么是中间件 中间件,是在操作系统之上,应用软件之下的中间层软件。本质上归结为技术架构。常见的中间件,包括服务治理中间件、配置中心、链路监控、分布式事务、分布式定时任务、分布式缓存、消息中间件、API网关、数据库中间件等 8、 什么是Spring Cloud 也是一个中间件,由Spring官方开发维护,基于SpringBoot技术框架,提供了一整套的微服务解决方案。包括服务注册与发现、配置中心、全链路监控、API网关、熔断器等组件,可以随需扩展或替换使用 9、 SpringCloud项目模块 注册中心 Eureka 第一代网关 Zuul 多语言 Sidecar 负载均衡 Ribbon 熔断器 Hystrix 第二代网关 gateway 集群监控 Turbine 声明式HTTP客户端 Feign 注册中心 consul 链路追踪 sleuth 配置中心 config 服务总线 Bus 等 10、 SpringCloud与服务治理中间件 服务治理中间件包含服务注册与发现、服务路由、复杂均衡、自我保护、丰富的治理管理机制等功能。服务路由包含服务上下线、在线测试、就近选择、A/B测试、灰度发布等,负载均衡支持根据状态权重进行负载。自我保护,服务降级、优雅降级、流量控制,Spring Cloud中使用了相关 11、 Springcloud与配置中心中间件 单体应用中,属性配置和代码采用硬编码形式放在一起,简单方便,但是在分布式系统中,多个服务实例,需要分别管理每个服务下对应的配置项,往往配置项项目一致,内容存在偏差,则上线需要检查所有的配置项,如果修改配置项,就要重启等,开发管理相当麻烦,另外还会涉及安全性的问题,比如数据库密码等的存放。分布式系统中,需要我们统一管理,负责管理的中间件,就是配置中心。配置中心,应该具备的功能,分别是支持各种复杂的配置场景,与公司的运维体系和权限体系集成一体,各种配置兼容支持。 SpringCloud Config是配置中心中间件,将应用原本放在本地的配置,统一放置到中心服务器,拥有了更好地管理发布能力,基于应用、环境、版本三个维度管理,配置存储支持git等。无缝支持Spring技术的Environment和PropertySource接口 12、 Springcloud与网关中间件 API是在系统边界上,面向API的串行集中式强管控服务,至少具备如下功能 I 统一接入功能,提供一个高性能、高并发、高可靠的网关服务,也要支持负载均衡、异地多活、容灾切换 Ii 协议适配功能,因为网关是集中式强管控,必须要提供满足各个请求协议,能够协议适配 Iii 流量管控 Iv 安全防护、权限校验 SpringCloud第一代网关采用zuul,根据默认或者配置的路由规则,进行负载或者路由,只能支持基本功能,如果想要实现高度定制更多功能,就需要,进行开发filter过滤器 SpringCloud第二代网关采用Gateway,zuul采用每个请求分配一个线程的方式,不能支持高并发,gateway采用netty框架,具有强大的高并发处理能力,且实现了网管基本功能,例如安全,监控,限流等 13、 Springcloud与全链路监控中间件 分布式系统下,对于日志追踪等,有迫切的需求,需要一个可视化展示监控平台,进行汇集。全链路监控中间件基本功能如下,定位慢调用:各种web服务调用,慢sql执行,定位各种错误,定位各种异常,展现服务依赖,展现调用链路,应用告警SpringCloud采用sleuth 14、 Springcloud与分布式事务 微服务架构之后,困难,在于,1)系统拆分后,服务间调用通信、故障处理变得复杂2)微服务化后,服务调用的分布式事务问题突出3)数量众多,测试部署运维复杂,那么随着Docker容器技术、Devops技术的发展,各种PAAS平台工具的退出,变得愈加容易。分布式事务没有统一方案 15、 Springcloud与领域驱动 微服务作为一种架构风格,提供了快速开发微服务应用的能力,但是对于业务如何开发,业务架构如何治理,架构如何防腐,还需要方法论进行指导,领域驱动作为业务治理和架构防腐的方法论,结合起来,才能更好地提供企业使用 16、 SpringCloud与gRPC协议 通过SpringCloud进行搭建微服务应用,服务间得通信往往采用的是Feign中间件形式,实现简单快捷的调用,底层采用的http形式,相对于gRPC协议或者RPC协议的调用来说,性能相对低下,因此,可以切换开源技术框架gRPC实现 17、 SpringCloud与Dubbo生态融合 SpringCloud与Dubbo在本质上不在一个领域没有可比性。Dubbo是一个基于RPC协议的通信框架,而SpringCloud是实现微服务中间件,随着发展,两者生态也在不断融合,目前已经开源了Spring-cloud-dubbo的项目

huc_逆天 2020-02-24 21:01:42 0 浏览量 回答数 0

回答

1、 描述下应用架构的发展历程 目前,架构的发展历程是从单体架构、分布式架构、SOA架构,再到如今流行的微服务架构 2、单体架构的优点、缺点 优点: I 易于开发,开发人员可在短时间内开发完成单体应用 II 易于测试 III 易于部署 缺点: I 灵活程度不够,一旦修改,自上而下需要整体部署,才可以展现出效果,同时开发效率低,降低团队灵活性 II 降低系统的性能 III 系统启动、重启缓慢 IV 扩展性差 3、 什么是传统的分布式架构 简单来说,就是按照业务垂直切分,每个应用都是一个单体架构,通过API接口互相调用 好处是,依赖解耦,理解清晰,开发便捷速度,缺点是调用存在风险,技术复杂,可靠性降低 4、 SOA架构的优点、缺点 面向服务的SOA架构,根据不同的业务建立不同的服务,优点,模块拆分,开发聚合,降低了耦合度,增加功能,增加子项目即可,方便部署,灵活的分布式部署 缺点,调用、交互采用远程通信,接口开发增加工作量 5、 什么是微服务技术 微服务架构在某种程度上是SOA架构的发展。微服务是一种架构风格,对于一个大型的复杂的业务应用系统,业务功能可以拆分为多个独立的微服务,各个服务间是松耦合的,通过各种远程通信协议,实现交互,各个服务可以独立部署、扩容、升降级 6、 目前流行的微服务解决方案 目前最常见的,包括两种,一种基于SpringCloud中间件的微服务解决方案,选型比较中立,内部组件,可以自由更换搭配使用,大致上三种,服务发现,一种Eureka,一种Consul,一种etcd或者阿里nacos,共用组件,服务调用组件Feign。负载均衡ribbon,熔断器hystrix,网关,zuul,gateway,等,配置中心,携程阿波罗,nacos,Config;全链路监控,zipkin,pinpoint,skywalking,其他组件 另一种基于Dubbo实现微服务解决方案,可以Dubbo,nacos,其他 7、 什么是中间件 中间件,是在操作系统之上,应用软件之下的中间层软件。本质上归结为技术架构。常见的中间件,包括服务治理中间件、配置中心、链路监控、分布式事务、分布式定时任务、分布式缓存、消息中间件、API网关、数据库中间件等 8、 什么是Spring Cloud 也是一个中间件,由Spring官方开发维护,基于SpringBoot技术框架,提供了一整套的微服务解决方案。包括服务注册与发现、配置中心、全链路监控、API网关、熔断器等组件,可以随需扩展或替换使用 9、 SpringCloud项目模块 注册中心 Eureka 第一代网关 Zuul 多语言 Sidecar 负载均衡 Ribbon 熔断器 Hystrix 第二代网关 gateway 集群监控 Turbine 声明式HTTP客户端 Feign 注册中心 consul 链路追踪 sleuth 配置中心 config 服务总线 Bus 等 10、 SpringCloud与服务治理中间件 服务治理中间件包含服务注册与发现、服务路由、复杂均衡、自我保护、丰富的治理管理机制等功能。服务路由包含服务上下线、在线测试、就近选择、A/B测试、灰度发布等,负载均衡支持根据状态权重进行负载。自我保护,服务降级、优雅降级、流量控制,Spring Cloud中使用了相关 11、 Springcloud与配置中心中间件 单体应用中,属性配置和代码采用硬编码形式放在一起,简单方便,但是在分布式系统中,多个服务实例,需要分别管理每个服务下对应的配置项,往往配置项项目一致,内容存在偏差,则上线需要检查所有的配置项,如果修改配置项,就要重启等,开发管理相当麻烦,另外还会涉及安全性的问题,比如数据库密码等的存放。分布式系统中,需要我们统一管理,负责管理的中间件,就是配置中心。配置中心,应该具备的功能,分别是支持各种复杂的配置场景,与公司的运维体系和权限体系集成一体,各种配置兼容支持。 SpringCloud Config是配置中心中间件,将应用原本放在本地的配置,统一放置到中心服务器,拥有了更好地管理发布能力,基于应用、环境、版本三个维度管理,配置存储支持git等。无缝支持Spring技术的Environment和PropertySource接口 12、 Springcloud与网关中间件 API是在系统边界上,面向API的串行集中式强管控服务,至少具备如下功能 I 统一接入功能,提供一个高性能、高并发、高可靠的网关服务,也要支持负载均衡、异地多活、容灾切换 Ii 协议适配功能,因为网关是集中式强管控,必须要提供满足各个请求协议,能够协议适配 Iii 流量管控 Iv 安全防护、权限校验 SpringCloud第一代网关采用zuul,根据默认或者配置的路由规则,进行负载或者路由,只能支持基本功能,如果想要实现高度定制更多功能,就需要,进行开发filter过滤器 SpringCloud第二代网关采用Gateway,zuul采用每个请求分配一个线程的方式,不能支持高并发,gateway采用netty框架,具有强大的高并发处理能力,且实现了网管基本功能,例如安全,监控,限流等 13、 Springcloud与全链路监控中间件 分布式系统下,对于日志追踪等,有迫切的需求,需要一个可视化展示监控平台,进行汇集。全链路监控中间件基本功能如下,定位慢调用:各种web服务调用,慢sql执行,定位各种错误,定位各种异常,展现服务依赖,展现调用链路,应用告警SpringCloud采用sleuth 14、 Springcloud与分布式事务 微服务架构之后,困难,在于,1)系统拆分后,服务间调用通信、故障处理变得复杂2)微服务化后,服务调用的分布式事务问题突出3)数量众多,测试部署运维复杂,那么随着Docker容器技术、Devops技术的发展,各种PAAS平台工具的退出,变得愈加容易。分布式事务没有统一方案 15、 Springcloud与领域驱动 微服务作为一种架构风格,提供了快速开发微服务应用的能力,但是对于业务如何开发,业务架构如何治理,架构如何防腐,还需要方法论进行指导,领域驱动作为业务治理和架构防腐的方法论,结合起来,才能更好地提供企业使用 16、 SpringCloud与gRPC协议 通过SpringCloud进行搭建微服务应用,服务间得通信往往采用的是Feign中间件形式,实现简单快捷的调用,底层采用的http形式,相对于gRPC协议或者RPC协议的调用来说,性能相对低下,因此,可以切换开源技术框架gRPC实现 17、 SpringCloud与Dubbo生态融合 SpringCloud与Dubbo在本质上不在一个领域没有可比性。Dubbo是一个基于RPC协议的通信框架,而SpringCloud是实现微服务中间件,随着发展,两者生态也在不断融合,目前已经开源了Spring-cloud-dubbo的项目

huc_逆天 2020-02-25 11:08:12 0 浏览量 回答数 0

回答

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点 (technical concerns)?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设,同时在这块也投入了很多时间去学习和研究,有一些经验和学习心得,可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同,微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现目标服务,同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同,目前主要的服务注册、发现和负载均衡方案有三种: 第一种是集中式 LB 方案,如下图 Fig 1,在服务消费者和服务提供者之间有一个独立的 LB,LB 通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy 等实现。LB 上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向 LB 发起请求,由 LB 以某种策略(比如 Round-Robin)做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力,能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢?通常的做法是通过 DNS,运维人员为服务配置一个 DNS 域名,这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单,在 LB 上也容易做集中式的访问控制,这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题,所有服务调用流量都经过 LB,当服务数量和调用量大的时候,LB 容易成为瓶颈,且一旦 LB 发生故障对整个系统的影响是灾难性的。另外,LB 在服务消费方和服务提供方之间增加了一跳 (hop),有一定性能开销。 第二种是进程内 LB 方案,针对集中式 LB 的不足,进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头,该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案,下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的 LB 组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高,一般采用能满足高可用分布式一致的组件(例如 Zookeeper, Consul, Etcd 等)来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案,LB 和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。但是,该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头,如果企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本。另外,一旦客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架,对应的组件分别是:Eureka 服务注册表,Karyon 服务端框架支持服务自注册和健康检查,Ribbon 客户端框架支持服务自发现和软路由。另外,阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将 LB 和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡,见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案,没有单点问题,一个 LB 进程挂了只影响该主机上的服务调用方,服务调用方和 LB 之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂,环节多,出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架,对应组件分别是:Zookeeper 作为服务注册表,Nerve 独立进程负责服务注册和健康检查,Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes,其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关 (Service Gateway),见图 Fig 4,网关是连接企业内部和外部系统的一道门,有如下关键作用: 服务反向路由,网关要负责将外部请求反向路由到内部具体的微服务,这样虽然企业内部是复杂的分布式微服务结构,但是外部系统从网关上看到的就像是一个统一的完整服务,网关屏蔽了后台服务的复杂性,同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫,所有外部请求必须经过网关,网关可以集中对访问进行安全控制,比如用户认证和授权,同时还可以分析访问模式实现防爬虫功能,网关是连接企业内外系统的安全之门。限流和容错,在流量高峰期,网关可以限制流量,保护后台系统不被大流量冲垮,在内部系统出现故障时,网关可以集中做容错,保持外部良好的用户体验。监控,网关可以集中监控访问量,调用延迟,错误计数和访问模式,为后端的性能优化或者扩容提供数据支持。日志,网关可以收集所有的访问日志,进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外,网关还可以实现线上引流,线上压测,线上调试 (Surgical debugging),金丝雀测试 (Canary Testing),数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层,有一定的计算逻辑,一般以集群方式部署,前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul,特点是动态可热部署的过滤器 (filter) 机制,其它如 HAproxy,Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务 Middle Tier Service)和前端服务(也称边缘服务 Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如 PC,Pad 或者 Phone)。后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看,网关类似 Proxy 代理或者 Façade 门面模式,而服务注册表和服务自注册自发现类似 IoC 依赖注入模式,微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源 (线程,队列等) 被耗尽,造成所谓的雪崩效应 (Cascading Failure,见图 Fig 7),严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括: Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失。在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮;如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态 (Closed),如果调用持续出错或者超时,电路被打开进入熔断状态 (Open),后续一段时间内的所有调用都会被拒绝 (Fail Fast),一段时间以后,保护器会尝试进入半熔断状态 (Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子,假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务,且部署 A 的容器一共有 120 个工作线程,采用线程隔离机制,可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程,当 Svc2 慢了,给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽,线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响,如果没有这种隔离机制,当 Svc2 慢的时候,120 个工作线程会很快全部被对 Svc2 的调用吃光,整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量 (秒杀,双十一) 时被冲垮。限流通常指对服务限定并发访问量,比如单位时间只允许 100 个并发调用,对超过这个限制的请求要拒绝并回退。回退 (fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败 (Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中,凡是需要容错的依赖点 (服务,缓存,数据库访问等),开发人员只需要将调用封装在 Hystrix Command 里头,则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证,是 Netflix 微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件。 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑,包括: Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查,假定采用进程内 LB 方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。监控日志,框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。REST/RPC 和序列化,框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来,HTTP/REST 是当前主流 API 暴露方式,在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出 Ajax 友好的 JSON 消息格式,而对无线设备上的 Native App,框架支持输出性能高的 Binary 消息格式。配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon,Spring 的 Spring Boot/Cloud,阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置,例如访问数据库有连接字符串配置,连接池大小和连接超时配置,这些配置在不同环境 (开发 / 测试 / 生产) 一般不同,比如生产环境需要配连接池,而开发测试环境可能不配,另外有些参数配置在运行期可能还要动态调整,例如,运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置,简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上,用户通过管理界面配置和调整服务配置,具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置,拉方式比较可靠,但会有延迟同时有无效网络开销 (假设配置不常更新),服务器推方式能及时更新配置,但是实现较复杂,一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题,对于大规模服务化环境,配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf,360 的 QConf,Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司,几年前,Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括: Eureka: 服务注册发现框架Zuul: 服务网关Karyon: 服务端框架Ribbon: 客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系,来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证,正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品,主要是基于对 Netflix 开源组件的进一步封装,方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说,充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud),在此基础上进行必要的企业定制,无疑是通向微服务架构的捷径。 原文地址:https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

回答

问题原因 支付宝返回内容信息验签失败。 1、支付宝公钥错误 2、编码格式错误 3、验签方法错误 解决方案 1、支付宝公钥错误 验签使用的支付宝公钥必须是与之匹配的应用id(app_id)中的支付宝公钥。 代码中支付宝公钥参数与开放平台上“接口加签方式”位置获取的支付宝公钥是否一致。 (大部分商户报错是由于支付宝公钥错误导致,需在开放平台的“接口加签方式”位置的支付宝公钥中获取,注意不是通过密钥生成工具生成的) 使用工具生成的密钥为应用私钥和应用公钥,应用公钥与支付宝公钥数据不同。 如果应用的“接口加签方式”设置为“公钥”,则获取支付宝公钥数据,使用支付宝公钥数据进行验签。 如果应用的“接口加签方式”设置为“公钥证书”,则获取支付宝公钥证书信息,使用支付宝公钥证书进行验签。 支付宝公钥获取详见如何获取支付宝公钥。 2、检查编码类型(charset)是否正确 如果编码格式不同一,会导致返回信息中文乱码,建议查看返回信息是否存在乱码等情况。 如果乱码请按照中文乱码的排查流程自行检查自己项目和服务器等环境的编码格式。 3、验签方法错误 接口报错sign check fail: check Sign and Data Fail!,都是商户通过sdk初始化调用接口,接口中已经自动封装验签代码,会对返回的同步响应参数进行验签,因此会存在支付成功,但是返回数据验签失败报错。 验签代码错误,主要会存在于.net开发语言初始化代码设置错误:.net版本调用sdk报错,建议检查初始化代码末尾是否为false。 示例代码: IAopClient client = new DefaultAopClient("https://openapi.alipay.com/gateway.do", "app_id", "merchant_private_key", "json", "1.0", "RSA2", "alipay_public_key", "GBK", false); 4、运行环境有误 如果本地测试成功,但是服务器上报错,那就应该不是代码问题,可能是操作系统运行环境不同导致的,建议检查你的运行环境版本是否过低,过低建议升级,.net的话需要.net framework 4.0的。

保持可爱mmm 2020-05-05 17:01:46 0 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 39926 浏览量 回答数 17

回答

云端接入域名和端口号是什么? 域名:js ${YourProductKey}.iot-as-mqtt.${YourRegionId}.aliyuncs.com 。 其中,${YourProductKey}请替换为您的产品ProductKey;${YourRegionId}请参见地域和可用区,替换为您在物联网平台创建产品时选择的地域代码。 端口: 1883。 使用MQTT协议连接,不同的设备可以使用相同的clientID连接服务器吗? clientID需为全局唯一。如果不同的设备使用相同的clientID同时连接物联网平台,那么先连接的那个设备会被强制断开。 如何开启域名直连? MQTT连接有两种方式。 认证后再连接:首先使用HTTPS连接到```js js iot-auth.cn-shanghai.aliyuncs.com:443 获取认证cert后,再使用MQTT连接到 ```js js/public.iot-as-mqtt.cn-shanghai.aliyuncs.com/1883。 认证连接必须使用TLS加密进行认证。 域名直连:连接域名:js ${productKey}.iot-as-mqtt.cn-shanghai.aliyuncs.com:1883 。 域名直连减少了HTTPS获取证书cert的过程。 资源受限的设备推荐使用域名直连。一些特殊增值服务,例如设备级别的引流,则推荐先HTTPS发送授权后再连接MQTT。在make.setting中设置js FEATURE_MQTT_DIRECT=y , 然后执行js make reconfig 即 可设置为先认证后再MQTT连接。 MQTT协议版本是多少? 在MQTT connect packet中设置MQTT的版本。目前SDK(V2.02)使用MQTT 3.1.1 。 可以修改SDK代码中js src\mqtt\mqtt_client.h IOTX_MC_MQTT_VERSION 的 值,来修改支持的版本。3:3.1版;4:3.1.1版。 MQTT进行设备认证时,server返回“400”错误 认证返回400错误,表示鉴权认证失败。请检查设备证书信息ProductKey、DeviceName和DeviceSecret是否正确。 C语言SDK中MQTT是否支持iOS接入? C语言SDK可以移植到任何能够支持C语言的系统上。如果是iOS系统建议寻找开源的Object-C实现。 目前mqtt-example设备上线后会立刻下线,请问如何修改mqtt-example让设备一直处于上线状态? mqtt-example程序发送一次消息后会自动退出,可以尝试以下任意一种方式实现长期在线。 执行mqtt-example时,使用命令行js ./mqtt-example loop , 设备会保持长期在线。修改demo代码。example 的代码在最后会调用IOT_MQTT_Destroy,设备最后会变成离线状态,所以可以修改代码,去掉IOT_MQTT_Unregister 和IOT_MQTT_Destroy。 while(1) { IOT_MQTT_Yield(pclient, 200); HAL_SleepMs(100); } 心跳的时间间隔如何设置? 在IOT_MQTT_Construct里面可以设置keepalive_interval_ms的取值。物联网平台使用这个值来作为心跳间隔时间。keepalive_interval_ms的取值范围是60000~300000。 设备端的重连机制是什么? 设备端会在keepalive_interval_ms时间间隔发送ping request,然后等待ping response。 如果设备端在keepalive_interval_ms时间内无法收到ping response,或是在进行send以及recv时发生错误,平台就认为此时网络断开,而需要进行重连。 重连机制是平台内部触发,无需使用者接入。重连时,会重新进行认证。如果认证成功就会开始再次进行MQTT connect。重连会一直持续直到再次连接成功。 云端如何侦测到设备离线? 云端会根据MQTT CONNECT packet里面keepalive的设置,等待ping request。如果在指定时间内没有收到ping request,则认为设备离线。 云端可以接受的最大时延是5秒。 设备端SDK是否支持MQTT和CCP协议的断线重连? 支持。测试场景描述:开发板通过WiFi连接上路由器后,把网线拔掉,MQTT和CCP协议都会自动尝试和server重新建立连接。尝试时间间隔是1s、2s、4s、8s、…,最大间隔时间默认是60s,也就是说断网后超过60s时间仍未连接成功,之后会每隔60s尝试和server重连。您可以设置最大间隔时间。 发布(Publish QoS1)数据时,偶尔会出现MQTT_PUSH_TO_LIST_ERROR(-42),如何解决? 需要等待ACK的packet都会存放起来,等待ACK。存放量有上限,当需要等待的packet太多到达上限时,就会触发js MQTT_PUSH_TO_LIST_ERROR(-42) error 。 出现错误可能是因为当前网络状态不好,或者是发送的频率过高。如果排除上述两个问题,当前的发送的频率是预期的,那么可以适当的调整IOTX_MC_REPUB_NUM_MAX、 IOTX_MC_SUB_REQUEST_NUM_MAX和IOTX_MC_SUB_NUM_MAX的大小。 如果业务允许,也可以把publish的QoS调整成0。 IOT_MQTT_Yield的作用是什么? IOT_MQTT_Yield的作用是尝试接收数据。因此在需要接收数据时,例如subscribe 和 unsubscribe之后,publish QoS1 消息之后,或是希望收到publish 数据时,都需要主动调用该函数。 IOT_MQTT_Yield参数timeout的意义是什么? IOT_MQTT_Yield会尝试接收数据,直到timeout时间到后才会退出。 IOT_MQTT_Yield与HAL_SleepMs的区别 IOT_MQTT_Yield与HAL_SleepMs都是阻塞一段时间,但是IOT_MQTT_Yield实质是去读取数据,而HAL_SleepMs则是系统什么也不做,等待timeout。 如何循环接收消息? 需要循环调用IOT_MQTT_Yield ,函数内自动维持心跳和接收数据。 订阅了多个Topic,调用一次IOT_MQTT_Yield,能接收到多个Topic的消息吗? 首先需要确定Topic的权限,是不是同时满足发布和订阅。如果是,调用一次IOT_MQTT_Yield,可以接收到多个packet。 MQTT连接方式,只能通过不停地调用IOT_MQTT_Yield来轮询获取数据吗? 如果使用的TCPIP协议栈,可以实现TCP主动通知上层有数据到达,可以改动实现事件触发的方式来触发IOT_MQTT_Yield。但是改动比较大,所以还请自行评估是否需要修改。 修改流程是: 调整utils_net.c里面socket的API,变成可以由TCP数据到达时回调的API。 当TCP主动通知上层有数据到达时,通知到MQTT服务器。让MQTT服务器内部执行IOT_MQTT_Yield,这样就可以不需要外部调用IOT_MQTT_Yield来读取数据。 如果TCP无法做到主动上报数据,但OS支持多线程,也可以在MQTT-example里面再起一个thread,在这个thread里面以下代码用于接收数据。收到数据时,触发主线程进行数据处理,而主线程大部分时间可以用于处理其他逻辑。 while(1) { IOT_MQTT_Yiled(pclient, 200); HAL_SleepMs(200); } 如果使用的系统也不支持多线程,就只能把IOT_MQTT_Yield的timeout时间间隔减小,然后提高调用的频率,在每次调用的时间间隔内执行其他操作,从而做到尽量减少对其他操作的阻塞。 是否支持QoS 2? 不支持。 什么情况下会发生订阅超时(subscribe timeout)? 在2倍request_timeout_ms时间内,系统未接收到SUBACK packet时,会触发订阅超时,并通过event_handle函数发送超时通知。 请在subscribe之后,立刻执行IOT_MQTT_Yield尝试读取SUBACK,请勿使用HAL_SleepMs。 subcribe时,返回IOTX_MQTT_EVENT_SUBCRIBE_NACK 请检查Topic的操作权限是否为订阅。 如果发布报错“no authorization”,请确认是否为发布权限。 MQTT 发布的消息体大小限制 MQTT的协议包受限于IOT_MQTT_Construct里参数的write_buf和read_buf的大小。 MQTT协议包大小不能超过256 KB。超过大小限制的消息会被丢弃。 MQTT协议pub消息payload格式是怎么样的? 物联网平台没有制定pub消息payload的具体字段有那些。您根据应用场景制定自己的协议,然后以JSON格式放到pub消息载体里面传给服务端。 ota_mqtt升级的时候报错“mqtt read buffer is too short” MQTT设置的buffer过小,即mqtt_param的pread_buf和pwrite_buf申请过小造成的。可以根据实际需要修改OTA_MQTT_MSGLEN的大小。 是否可以使用MQTT直连的方式进行OTA升级? OTA升级时,必须使用HTTPS进行固件下载。MQTT只接收版本更新指令,与MQTT的连接方式无关。阿里云不支持HTTP下载固件,因此如果设备没有SSL通信的能力,则不能使用OTA服务。 打开MQTT over TLS,运行时提示MQTT创建失败,返回错误码0x2700 如果关闭MQTT over TLS则可以成功地订阅和发布信息;打开MQTT over TLS时,建连失败。首先确认mbedtls是否做了修改,这是用于传输层和应用层之间加密的功能,不能随意更改。mbedtls没有修改,则考虑系统时间是否正确,系统时间不对也会导致证书校验失败。 进行mqtt连接的时候,是否需要root.crt证书验证? 若使用TLS进行MQTT接入,需要下载根证书。 若使用物联网平台提供的demo进行开发,无需再下载根证书,demo中已自带证书。 物联网平台支持哪些QoS Level? 在MQTT协议和CCP协议下,阿里云物联网平台支持的QoS Level都包括0和1。

剑曼红尘 2020-03-05 12:51:20 0 浏览量 回答数 0

问题

游戏盾SDK接入指南的介绍

云栖大讲堂 2019-12-01 21:49:47 3560 浏览量 回答数 0

问题

荆门开诊断证明-scc

游客5k2abgdj3m2ti 2019-12-01 22:09:00 1 浏览量 回答数 0

问题

个推推送Android问题检测 - 安卓报错

montos 2020-06-01 12:47:32 0 浏览量 回答数 1

问题

个推推送Android问题检测 :配置报错 

kun坤 2020-05-31 21:38:58 1 浏览量 回答数 1

问题

使用HTTPDNS时该如何API访问

猫饭先生 2019-12-01 21:51:27 1353 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

MaxCompute百问集锦

yq传送门 2019-12-01 20:16:47 2404 浏览量 回答数 1

问题

SaaS模式云数据仓库MaxCompute 百问百答合集(持续更新20201031)

亢海鹏 2020-05-29 15:10:00 26755 浏览量 回答数 35

问题

大数据时代——数据存储技术百问

yq传送门 2019-12-01 20:27:42 31965 浏览量 回答数 35

问题

随手科技拥抱OneAPM:打造高标准真实用户体验

sunny夏筱 2019-12-01 21:42:04 7083 浏览量 回答数 4

回答

一 、iOS APP 上架流程简介 1. 申请开发者账号 苹果的开发者账号主要分为个人(Individual)、公司(Company)、企业(Enterprise)、高校(University)四种类型,每年资费分别为$99、$99、$299、免费)。一般开发者申请的都是个人或者公司的,企业的开发者账号开发应用不能发布到App Store,只能企业内部使用。这个申请过程一般可能需要一个星期左右。公司和企业的需要邓白氏码,如果邓白氏码未申请,请先申请邓白氏码,这个过程需要一到两个星期。 创建证书、AppID、生成描述文件 通过 Mac 的钥匙串工具,生成证书请求文件,下载证书,这里需要注意的是下载下来的证书只能在请求该证书的电脑上使用,如果想给其他开发者使用需要将已经导入的证书导出为个人信息交换(.p12)格式供他人使用。 AppID 的创建需要用到项目的 Bundle ID,之后便可以创建描述文件了。 在开发者中心的 iTunes Connect 中配置 App 相关信息 在开发者中心里的 iTunes Connect 里的 APP 选项中新建 APP 项目并配置相应的信息(需要各个版本的屏幕截图,运行模拟器,调到最大(command+1)用 command+s 截图,还有就是一个1024*1024的图标,不能有圆角) 使用 Xcode 打包上传 App 将 2 步骤中申请好的证书和描述文件正确配置到 Xcode 中,设置好Xcode 的一些属性: 在Xcode中选择iOS Device(这里不能选择模拟器) 如果应用不支持横屏,请在 General 选项中将 Landscape Left 和 Landscape Right 两项的勾选去掉 查看版本号和构建版本号 将断点、全局断点、僵尸模式等都去掉 设置为 Release 模式 之后便可选择 Xcode->Product->Archive 打包项目,打包完成后选择 Upload to App Store 上传。如果不想使用 Xcode 上传的话,也可以选择 Export 导出 ipa 文件, 需要注意的是在导出时,必须选择 Save for iOS App Store Deployment。然后通过Application Loader 工具上传 ipa 文件。 提交审核 以上步骤完成后,返回 iTunes Connect 上查看自己的 App 信息,在构建版本中选择刚刚上传的 App 版本,此时有可能显示正在处理,这时可能需要等几分钟再回来查看。选择好版本后点击提交以供审核,这时 App 会变成等待审核状态。 后续 后续就是等待苹果的审核人员审核应用了,如果一切顺利的话,这个过程需要一到两个工作日便可完成审核,当然前提是你的应用符合苹果的审核条款。如果审核不通过,请及时根据反馈信息修改应用,再次提交直到符合要求。审核通过后,如果之前选择已经选择好自动发布,便可在 AppStore 上查看和下载应用了。 二 、iOS 上架审核过程常见的坑与解决方法 1. 问题:用户生成内容(UGC)缺少必要的审核 为了防止非法滥用用户生成的内容,从而给用户提供虚假信息、盗取用户的知识产权,社交应用以及应用当中包含用户生成的信息的应用必须包括下述功能: 过滤不良内容 提供举报机制 后台服务可以提供阻止骚扰用户的行为 提供官方联系方式,让用户可以快速联系到开发商 解决方案: 维秀直播 App 提供了用户实时弹幕功能,所以涉及到了 UGC,他们的处理方法是增加关键词过滤,还有通过房管的方式人工审核,处理违规用户。 问题:应用中使用了 IDFA 被拒绝 IDFA 主要被用于广告中区分设备的作用。AppStore 禁止没有使用广告而采集 IDFA 的 App 上架,所以如果 App 本身没有广告的话,使用第三方 SDK 要注意检查是否含有 IDFA 广告模块。 解决方案: 如果应用本身有集成广告的话,只需要在提交审核的时候勾选正确的广告标识符选项即可。 如果应用本身未集成广告,却包含 IDFA 的话。这种情况一般都是集成的第三方 SDK 中包含 IDFA 导致的。首先寻找是否有不包含 IDFA 的 SDK 版本,如果没有的话可以参考 ShareSDK 的解决方法,通过后台配置在审核期间为应用添加广告,审核完成过后将广告展示去掉。 3. 问题:应用不支持 IPv6网络下使用 2016年6月1号起,苹果的审核人员会在 IPv6 网络上审核你的应用,所以如果你的应用程序无法使用 IPv6 协议,可能会被拒绝。 解决方案: 卓易夺宝和乐动听 App 上架过程中就因为 IPv6 的支持原因被拒。他们的解决方案是: 协调后端人员添加对 IPv6 网络的支持。 App 端更新相关的第三方 SDK,比如使用 ASI 或者 AFN 的版本太低,使用最新的 AFN 即可解决问题。 当然这些做完之后最好在Mac 上面搭建 IPv6网络供测试人员进行完测试再重新发布。 4. 问题:第三方登录、支付、分享未安装应用,提示下载被拒 这个问题其实被拒的原因有两种,第一种是未安装应用没有任何提示,这种情况下相当于应用有无效的按钮所以会被拒;第二种是提示下载对应的第三方 App,这也是苹果所不允许的。 解决方案: 最新的第三方登录等相关的 SDK 目前已知的(微信,QQ,微博)都已经对这种情况做了处理,在未安装的情况下会调用 web 进行登录,所以如果测试过程中发现可以成功在 web 上登录的话可以不做处理。以前在没有这种处理机制的情况下需要开发者调用对应接口,先判断是否安装了相应的第三方 APP,如果未安装,需要隐藏按钮,这样便可轻松过审。 问题:虚拟产品未使用应用内支付(IAP)被拒 根据苹果官方最新的审核条款:如果你希望通过付费才可以解锁你的应用当中的一些功能(例如,订阅内容,游戏货币,游戏关卡,获取优质内容,解锁完整版本),你必须使用应用内付费(IAP)。如果这种情况下,应用使用了其他的第三方支付,应用将被拒绝上架。 解决方案: 审核的时候,把相应的虚拟产品隐藏起来,通过后再放出来,此招有风险,可能会受到警告信,甚至被封号,如果用户量小就无所谓了,先把App 搞上架! 审核的时候,走 IAP 的支付方式,审核完成后再通过服务器配置动态切换到支付宝、微信等第三方支付。该法类似于方案1,也存在风险。 学习58同城,让用户去网站购买产品,买了产品的账号到移动端使用功能。 老老实实的使用 IAP 吧。 6. 问题:使用后台定位被拒 关于位置服务苹果的审核条款原文如下: 使用位置服务的应用程序必须提供和位置服务直接相关的功能。使用基于位置的API不允许用于提供紧急服务,或者实现自动控制车辆、飞行器以及其他设备(小型的设备例如小型无人机和玩具例外),远程控制汽车警报系统等。在收集、传输和使用用户的位置数据之前,请确保你已经取得了用户的同意。 如果应用程序使用了后台定位服务,务必在应用当中阐明其目的。并且使用后台定位的话需要提供一个明确的提醒告诉用户这么做会加快电量消耗。 一般应用在这一块被拒的原因有以下几种: 应用根本不需要定位功能。 应用需要定位功能,但是只需要短暂的获取少数的用户的位置,比如美团,新闻类的应用需要获得当前用户的所在城市,却使用了后台定位模式。 应用确实需要使用后台定位,比如打车类软件,但是应用中却没有任何界面展示这些定位数据。 解决方案: 如果你的应用根本不需要定位功能,但是还是在 info.plist 里面添加了 location in the UIBackgroundModes key ,那么在 plist 文件里面移除 UIBackgroundModes key 就可以,这中情况较少,新手小白会犯这种错误。 如果只是简单获取位置不需要使用后台定位,只需要去掉info.plist 的文件中的 UIBackgroundModes 即可。 这种情况比较复杂,推荐的做法是通过表格或者轨迹展示出后台定位的数据,再提交审核的时候告诉苹果那个功能需要后台定位,具体展示后台定位的 数据在那个界面,最后需要 Continued use of GPS running in the background can dramatically decrease battery life加到 App 描述里 面,可以参考滴滴出行的描述,否则也会被拒绝。 7. 问题:info.plist 权限配置被拒 iOS 10 之后如果需要调用相机,蓝牙等设备时,需要在 info.plist 文件中进行相应的配置,否则应用会直接崩溃,在 iOS 10 之前则是无法访问。另外,如果在 info.plist 中调用了配置了权限在应用中却没有使用到也是会被拒的。 解决方案: 一定要注意自己的 App 在使用中用到了哪些权限,不要添加无用的权限,也不要缺少必要的权限。 问题:应用提示更新被拒 应用内不能有任何提示更新应用的字样,且应用的更新只能通过 AppStore。因为苹果对于应用的更新有自己的一套策略,所以禁止应用本身提供更新方式,只要应用内出现。 解决方案: 如果不是很必要的话,尽量将应用内涉及到应用更新的部分去掉。如果真的需要使用应用更新,推荐的方法是应用启动的时候获取下应用在 AppStore 上面的版本号,与自己的版本号进行比较,当自己的版本号小于 AppStore 上面的版本号时,提示更新,否则的话不显示更新相关的内容。 问题:夺宝(抽奖)类应用被拒 根据 AppStore 审核准则 20.4 的规定,抽奖卷或抽奖参与权的购买,不论是透过第三方支付渠道或者余额扣款实现,都不能够在 app 内执行。 解决方案: 卓易夺宝 App 上架过程中遇到的问题,最后的解决方法是在审核过程中,所有的支付行为都跳转到 Safari 浏览器上面进行,审核完成后再使用支付宝等 app 平台支付。 问题:隐私条款问题被拒 在未获得用户事先允许,或未告知用户信息将被如何,在哪里使用的情况下,应用不可以传输用户数据。 解决方案: 《网站服务协议》《隐私条款》这些都不要少,注册时候让用户可勾选。另外注明需要的用户信息用来做什么。 问题:未提供测试账号被拒 如果应用中有需要用到账号或者其他资源的(例如:一个二维码)才能使用的一些功能,但未提供给苹果,可能会被拒绝上架。原因是苹果审核人员无法测试这些功能。 解决方案: 提供一个有效的测试帐号以及登录信息,并提供测试功能必要的的硬件和资源(例如,一个测试用的二维码) 问题:未通过 HTTPS 访问被拒 App Transport Security(ATS) 是 Apple 为增强 iOS App 网络通信安全提出的安全功能,适用于 iOS App 和 App Extension;在启用 ATS 之后,它会强制应用通过 HTTPS(而不是 HTTP )连接网络服务。 WWDC 2016上提出,2016年底或2017年初,具体时间未定。App Store 上架审核加强对 ATS 配置的 review,即强制应用必须通过 HTTPS 连接网络服务,而不是随手将 NSAllowsArbitraryLoads 置为 YES,否则审核不予通过。 解决方案: ATS 的提出,是为了在系统层面保障 iOS APP 网络通信的安全;Apple 只所以加强对 ATS 配置的审核,是为了防止开发者们遇到ATS相关的场景时,只是简单地将 ATS完全关闭(只要没有强制性措施,开发者会这么做);在此基础上,App 审核同样会遵循原则:App Review will require "reasonable justification" for most ATS exceptions。 Apple 官方给出的可以通过审核的声明 demo 如下: 必须使用第三方提供的服务,但是其没有支持 HTTPS; 必须通过域名连接到设备,但该设备不能支持安全连接; 必须展示不同来源的网页内容,但是不能基于 NSAllowsArbitraryLoadsInWebContent 支持的类(UIWebView / WKWebView)实现; 载入加密的媒体资源并且其中不涉及个人信息。 由于 Apple 官方并没有给出 ATS 审核的完整说明,ATS 审核时什么才是合适合理的声明也没有明确的客观定义,以上 demo 描述仅能作为参照。 参考文章: http://www.jianshu.com/p/b1b77d804254 https://github.com/wg689/Solve-App-Store-Review-Problem 22人点赞 iOS 作者:Jon1993 链接:https://www.jianshu.com/p/a992c88087a5 来源:简书

一只刺猬 2020-03-27 10:03:40 0 浏览量 回答数 0

问题

个推推送Android问题检测:报错

kun坤 2020-06-13 23:53:00 0 浏览量 回答数 1

问题

MaxCompute百问集锦(持续更新20171011)

隐林 2019-12-01 20:19:23 38430 浏览量 回答数 18

问题

【阿里云产品公测】以开发者角度看ACE服务『ACE应用构建指南』

mr_wid 2019-12-01 21:10:06 20092 浏览量 回答数 6

问题

Apache Flink常见问题汇总【精品问答】

黄一刀 2020-05-19 17:51:47 11230 浏览量 回答数 2

回答

Go 的优势在于能够将简单的和经过验证的想法结合起来,同时避免了其他语言中出现的许多问题。本文概述了 Go 背后的一些设计原则和工程智慧,作者认为,Go 语言具备的所有这些优点,将共同推动其成为接替 Java 并主导下一代大型软件开发平台的最有力的编程语言候选。很多优秀的编程语言只是在个别领域比较强大,如果将所有因素都纳入考虑,没有其他语言能够像 Go 语言一样“全面开花”,在大型软件工程方面,尤为如此。 基于现实经验 Go 是由经验丰富的软件行业老手一手创建的,长期以来,他们对现有语言的各种缺点有过切身体会的痛苦经历。几十年前,Rob Pike 和 Ken Thompson 在 Unix、C 和 Unicode 的发明中起到了重要作用。Robert Griensemer 在为 JavaScript 和 Java 开发 V8 和 HotSpot 虚拟机之后,在编译器和垃圾收集方面拥有数十年的经验。有太多次,他们不得不等待 Google 规模的 C++/Java 代码库进行编译。于是,他们开始着手创建新的编程语言,将他们半个世纪以来的编写代码所学到的一切经验包含进去。 专注于大型工程 小型工程项目几乎可以用任何编程语言来成功构建。当成千上万的开发人员在数十年的持续时间压力下,在包含数千万行代码的大型代码库上进行协作时,就会发生真正令人痛苦的问题。这样会导致一些问题,如下: 较长的编译时间导致中断开发。代码库由几个人 / 团队 / 部门 / 公司所拥有,混合了不同的编程风格。公司雇佣了数千名工程师、架构师、测试人员、运营专家、审计员、实习生等,他们需要了解代码库,但也具备广泛的编码经验。依赖于许多外部库或运行时,其中一些不再以原始形式存在。在代码库的生命周期中,每行代码平均被重写 10 次,被弄得千疮百痍,而且还会发生技术偏差。文档不完整。 Go 注重减轻这些大型工程的难题,有时会以使小型工程变得更麻烦为代价,例如,代码中到处都需要几行额外的代码行。 注重可维护性 Go 强调尽可能多地将工作转给自动化的代码维护工具中。Go 工具链提供了最常用的功能,如格式化代码和导入、查找符号的定义和用法、简单的重构以及代码异味的识别。由于标准化的代码格式和单一的惯用方式,机器生成的代码更改看起来非常接近 Go 中人为生成的更改并使用类似的模式,从而允许人机之间更加无缝地协作。 保持简单明了 初级程序员为简单的问题创建简单的解决方案。高级程序员为复杂的问题创建复杂的解决方案。伟大的程序员找到复杂问题的简单解决方案。 ——Charles Connell 让很多人惊讶的一点是,Go 居然不包含他们喜欢的其他语言的概念。Go 确实是一种非常小巧而简单的语言,只包含正交和经过验证的概念的最小选择。这鼓励开发人员用最少的认知开销来编写尽可能简单的代码,以便许多其他人可以理解并使用它。 使事情清晰明了 良好的代码总是显而易见的,避免了那些小聪明、难以理解的语言特性、诡异的控制流和兜圈子。 许多语言都致力提高编写代码的效率。然而,在其生命周期中,人们阅读代码的时间却远远超过最初编写代码所需的时间(100 倍)。例如,审查、理解、调试、更改、重构或重用代码。在查看代码时,往往只能看到并理解其中的一小部分,通常不会有完整的代码库概述。为了解释这一点,Go 将所有内容都明确出来。 错误处理就是一个例子。让异常在各个点中断代码并在调用链上冒泡会更容易。Go 需要手动处理和返回每个错误。这使得它可以准确地显示代码可以被中断的位置以及如何处理或包装错误。总的来说,这使得错误处理编写起来更加繁琐,但是也更容易理解。 简单易学 Go 是如此的小巧而简单,以至于人们可以在短短几天内就能研究通整个语言及其基本概念。根据我们的经验,培训用不了一个星期(相比于掌握其他语言需要几个月),初学者就能够理解 Go 专家编写的代码,并为之做出贡献。为了方便吸引更多的用户,Go 网站提供了所有必要的教程和深入研究的文章。这些教程在浏览器中运行,允许人们在将 Go 安装到本地计算机上之前就能够学习和使用 Go。 解决之道 Go 强调的是团队之间的合作,而不是个人的自我表达。 在 Go(和 Python)中,所有的语言特性都是相互正交和互补的,通常有一种方法可以做一些事情。如果你想让 10 个 Python 或 Go 程序员来解决同一个问题,你将会得到 10 个相对类似的解决方案。不同的程序员在彼此的代码库中感觉更自在。在查看其他人的代码时,国骂会更少,而且人们的工作可以更好地融合在一起,从而形成了一致的整体,人人都为之感到自豪,并乐于工作。这还避免了大型工程的问题,如: 开发人员认为良好的工作代码很“混乱”,并要求在开始工作之前进行重写,因为他们的思维方式与原作者不同。 不同的团队成员使用不同的语言子集来编写相同代码库的部分内容。 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/e64418f1455d46aaacfdd03fa949f16d.png) 简单、内置的并发性 Go 专为现代多核硬件设计。 目前使用的大多数编程语言(Java、JavaScript、Python、Ruby、C、C++)都是 20 世纪 80 年代到 21 世纪初设计的,当时大多数 CPU 只有一个计算内核。这就是为什么它们本质上是单线程的,并将并行化视为边缘情况的马后炮。通过现成和同步点之类的附加组件来实现,而这些附加组件既麻烦又难以正确使用。第三方库虽然提供了更简单的并发形式,如 Actor 模型,但是总有多个可用选项,结果导致了语言生态系统的碎片化。今天的硬件拥有越来越多的计算内核,软件必须并行化才能高效运行。Go 是在多核处理器时代编写的,并且在语言中内置了简单、高级的 CSP 风格并发性。 面向计算的语言原语 就深层而言,计算机系统接收数据,对其进行处理(通常要经过几个步骤),然后输出结果数据。例如,Web 服务器从客户端接收 HTTP 请求,并将其转换为一系列数据库或后端调用。一旦这些调用返回,它就将接收到的数据转换成 HTML 或 JSON 并将其输出给调用者。Go 的内置语言原语直接支持这种范例: 结构表示数据 读和写代表流式 IO 函数过程数据 goroutines 提供(几乎无限的)并发性 在并行处理步骤之间传输管道数据 因为所有的计算原语都是由语言以直接形式提供的,因此 Go 源代码更直接地表达了服务器执行的操作。 OO — 好的部分 更改基类中的某些内容的副作用 面向对象非常有用。过去几十年来,面向对象的使用富有成效,并让我们了解了它的哪些部分比其他部分能够更好地扩展。Go 在面向对象方面采用了一种全新的方法,并记住了这些知识。它保留了好的部分,如封装、消息传递等。Go 还避免了继承,因为它现在被认为是有害的,并为组合提供了一流的支持。 现代标准库 目前使用的许多编程语言(Java、JavaScript、Python、Ruby)都是在互联网成为当今无处不在的计算平台之前设计的。因此,这些语言的标准库只提供了相对通用的网络支持,而这些网络并没有针对现代互联网进行优化。Go 是十年前创建的,当时互联网已全面发展。Go 的标准库允许在没有第三方库的情况下创建更复杂的网络服务。这就避免了第三方库的常见问题: 碎片化:总是有多个选项实现相同的功能。 膨胀:库常常实现的不仅仅是它们的用途。 依赖地狱:库通常依赖于特定版本的其他库。 未知质量:第三方代码的质量和安全性可能存在问题。 未知支持:第三方库的开发可能随时停止支持。 意外更改:第三方库通常不像标准库那样严格地进行版本控制。 关于这方面更多的信息请参考 Russ Cox 提供的资料 标准化格式 Gofmt 的风格没有人会去喜欢,但人人都会喜欢 gofmt。 ——Rob Pike Gofmt 是一种以标准化方式来格式化 Go 代码的程序。它不是最漂亮的格式化方式,但却是最简单、最不令人生厌的格式化方式。标准化的源代码格式具有惊人的积极影响: 集中讨论重要主题: 它消除了围绕制表符和空格、缩进深度、行长、空行、花括号的位置等一系列争论。 开发人员在彼此的代码库中感觉很自在, 因为其他代码看起来很像他们编写的代码。每个人都喜欢自由地按照自己喜欢的方式进行格式化代码,但如果其他人按照自己喜欢的方式格式化了代码,这么做很招人烦。 自动代码更改并不会打乱手写代码的格式,例如引入了意外的空白更改。 许多其他语言社区现在正在开发类似 gofmt 的东西。当作为第三方解决方案构建时,通常会有几个相互竞争的格式标准。例如,JavaScript 提供了 Prettier 和 StandardJS。这两者都可以用,也可以只使用其中的一个。但许多 JS 项目并没有采用它们,因为这是一个额外的决策。Go 的格式化程序内置于该语言的标准工具链中,因此只有一个标准,每个人都在使用它。 快速编译 ![image.png](https://ucc.alicdn.com/pic/developer-ecology/8a76f3f07f484266af42781d9e7b8692.png) 对于大型代码库来说,它们长时间的编译是促使 Go 诞生的原因。Google 主要使用的是 C++ 和 Java,与 Haskell、Scala 或 Rust 等更复杂的语言相比,它们的编译速度相对较快。尽管如此,当编译大型代码库时,即使是少量的缓慢也会加剧编译的延迟,从而激怒开发人员,并干扰流程。Go 的设计初衷是为了提高编译效率,因此它的编译器速度非常快,几乎没有编译延迟的现象。这给 Go 开发人员提供了与脚本类语言类似的即时反馈,还有静态类型检查的额外好处。 交叉编译 由于语言运行时非常简单,因此它被移植到许多平台,如 macOS、Linux、Windows、BSD、ARM 等。Go 可以开箱即用地为所有这些平台编译二进制文件。这使得从一台机器进行部署变得很容易。 快速执行 Go 的运行速度接近于 C。与 JITed 语言(Java、JavaScript、Python 等)不同,Go 二进制文件不需要启动或预热的时间,因为它们是作为编译和完全优化的本地代码的形式发布的。Go 的垃圾收集器仅引入微秒量级的可忽略的停顿。除了快速的单核性能外,Go 还可以轻松利用所有的 CPU 内核。 内存占用小 像 JVM、Python 或 Node 这样的运行时不仅仅在运行时加载程序代码,每次运行程序时,它们还会加载大型且高度复杂的基础架构,以进行编译和优化程序。如此一来,它们的启动时间就变慢了,并且还占用了大量内存(数百兆字节)。而 Go 进程的开销更小,因为它们已经完全编译和优化,只需运行即可。Go 还以非常节省内存的方式来存储数据。在内存有限且昂贵的云环境中,以及在开发过程中,这一点非常重要。我们希望在一台机器上能够快速启动整个堆栈,同时将内存留给其他软件。 部署规模小 Go 的二进制文件大小非常简洁。Go 应用程序的 Docker 镜像通常比用 Java 或 Node 编写的等效镜像要小 10 倍,这是因为它无需包含编译器、JIT,以及更少的运行时基础架构的原因。这些特点,在部署大型应用程序时很重要。想象一下,如果要将一个简单的应用程序部署到 100 个生产服务器上会怎么样?如果使用 Node/JVM 时,我们的 Docker 注册表就必须提供 100 个 docker 镜像,每个镜像 200MB,那么一共就需要 20GB。要完成这些部署就需要一些时间。想象一下,如果我们想每天部署 100 次的话,如果使用 Go 服务,那么 Docker 注册表只需提供 10 个 docker 镜像,每个镜像只有 20MB,共只需 2GB 即可。大型 Go 应用程序可以更快、更频繁地部署,从而使得重要更新能够更快地部署到生产环境中。 独立部署 Go 应用程序部署为一个包含所有依赖项的单个可执行文件,并无需安装特定版本的 JVM、Node 或 Python 运行时;也不必将库下载到生产服务器上,更无须对运行 Go 二进制文件的机器进行任何更改。甚至也不需要讲 Go 二进制文件包装到 Docker 来共享他们。你需要做的是,只是将 Go 二进制文件放到服务器上,它就会在那里运行,而不用关心服务器运行的是什么。前面所提到的那些,唯一的例外是使用net和os/user包时针对对glibc的动态链接。 供应依赖关系 Go 有意识避免使用第三方库的中央存储库。Go 应用程序直接链接到相应的 Git 存储库,并将所有相关代码下载(供应)到自己的代码库中。这样做有很多好处: 在使用第三方代码之前,我们可以对其进行审查、分析和测试。该代码就和我们自己的代码一样,是我们应用程序的一部分,应该遵循相同的质量、安全性和可靠性标准。 无需永久访问存储依赖项的各个位置。从任何地方(包括私有 Git repos)获取第三方库,你就能永久拥有它们。 经过验收后,编译代码库无需进一步下载依赖项。 若互联网某处的代码存储库突然提供不同的代码,这也并不足为奇。 即使软件包存储库速度变慢,或托管包不复存在,部署也不会因此中断。 兼容性保证 Go 团队承诺现有的程序将会继续适用于新一代语言。这使得将大型项目升级到最新版本的编译器会非常容易,并且可从它们带来的许多性能和安全性改进中获益。同时,由于 Go 二进制文件包含了它们需要的所有依赖项,因此可以在同一服务器上并行运行使用不同版本的 Go 编译器编译的二进制文件,而无需进行复杂的多个版本的运行时设置或虚拟化。 文档 在大型工程中,文档对于使软件可访问性和可维护性非常重要。与其他特性类似,Go 中的文档简单实用: 由于它是嵌入到源代码中的,因此两者可以同时维护。 它不需要特殊的语法,文档只是普通的源代码注释。 可运行单元测试通常是最好的文档形式。因此 Go 要求将它们嵌入到文档中。 所有的文档实用程序都内置在工具链中,因此每个人都使用它们。 Go linter 需要导出元素的文档,以防止“文档债务”的积累。 商业支持的开源 当商业实体在开放式环境下开发时,那么一些最流行的、经过彻底设计的软件就会出现。这种设置结合了商业软件开发的优势——一致性和精细化,使系统更为健壮、可靠、高效,并具有开放式开发的优势,如来自许多行业的广泛支持,多个大型实体和许多用户的支持,以及即使商业支持停止的长期支持。Go 就是这样发展起来的。 缺点 当然,Go 也并非完美无缺,每种技术选择都是有利有弊。在决定选择 Go 之前,有几个方面需要进行考虑考虑。 未成熟 虽然 Go 的标准库在支持许多新概念(如 HTTP 2 Server push 等)方面处于行业领先地位,但与 JVM 生态系统中的第三方库相比,用于外部 API 的第三方 Go 库可能不那么成熟。 即将到来的改进 由于清楚几乎不可能改变现有的语言元素,Go 团队非常谨慎,只在新特性完全开发出来后才添加新特性。在经历了 10 年的有意稳定阶段之后,Go 团队正在谋划对语言进行一系列更大的改进,作为 Go 2.0 之旅的一部分。 无硬实时 虽然 Go 的垃圾收集器只引入了非常短暂的停顿,但支持硬实时需要没有垃圾收集的技术,例如 Rust。 结语 本文详细介绍了 Go 语言的一些优秀的设计准则,虽然有的准则的好处平常看起来没有那么明显。但当代码库和团队规模增长几个数量级时,这些准则可能会使大型工程项目免于许多痛苦。总的来说,正是这些设计准则让 Go 语言成为了除 Java 之外的编程语言里,用于大型软件开发项目的绝佳选择。

有只黑白猫 2020-01-07 14:11:38 0 浏览量 回答数 0

问题

支付宝的性能测试

云效平台 2019-12-01 21:47:13 5472 浏览量 回答数 1
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板