• 关于

    中小企业三端小程序技术框架选型

    的搜索结果

回答

微服务 (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

回答

“求知若饥,虚心若愚”——这个原本出自《全球概览》的俳句,因为乔布斯在斯坦福大学毕业演讲中的引用而备受推崇,流传成为 IT 界的至理名言之一。在编程界,亦有“代码胜于雄辩”、“Done is better than perfect”等警句,寥寥数语将编程工作者的形象特质描摹到了极致。程序员,就是技术至上、唯代码是瞻且必须不断武装自己的群体。 21 世纪,高薪、高端、高技术范儿已成为程序员的固有标签,在这个新的元年,CSDN 将基于一年一度的开发者大调查数据,以全新的视角深入发掘中国开发者群体的整体现状、应用开发技术以及开发工具/平台的发展趋势,呈现更真实、更全面且更有学习价值的开发者画像。 30 岁以下开发者人数占比超八成,全国有 19.6% 开发者月薪超过 1.7 万元; 六成开发者在使用 Java 语言,近五成开发者近期最想学 Python 语言; Spark、Redis 和 Kafka 正在成为企业大数据平台通用技术组件; 区块链技术近两年是热点,比特币和以太坊是两种主流的区块链开发平台; 人工智能技术日益受到企业和市场的关注,但 64% 企业尚未实现智能化,机器学习/深度学习算法工程师最为急缺; 近七成开发者认为未来 5G 网络的传输速率能达到 4G 网络的 10 倍以上; Apache 项目和 Linux 是开发者较为喜欢的开源项目; 半数开发者很少参与开源项目的开发、维护、运营和社区发展等。 软件开发准入门槛持续降低,近 2 成开发者月薪超过 1.7 万 30 岁以下开发者人数占比超八成,软件开发从业门槛持续降低 从 2015 年到 2019 年的调研数据来看:30 岁及以下的开发者人群占比在 8 成以上,一直是软件开发领域的主力军;全国近半数的开发者工作在一线城市(北京、上海、广州、深圳、天津);物联网、软件、IT 制造三个技术领域涵盖了国内 84% 以上的开发者;本科及以上学历占 8 成;92% 的开发者是男性。 和国外开发者年龄分布趋势大概一致,国内的软件开发群体一直呈现出越来越年轻化的特点。这是因为,一方面软件开发行业蓬勃发展,各行各业都需要软件开发相关人才,也有越来越多的毕业生选择从事该行业;另一方面,是因为编程语言、框架、云服务等基础设施的持续完善,从事软件开发的门槛在持续降低,更容易接纳新鲜血液,报告统计发现,本科学历是开发者的主力军,66% 的开发者拥有本科学历,而硕士研究生、博士研究生仅占 11%、1%。 八成以上开发者月薪在 5 千~3 万元之间,19.6% 开发者月薪超过 1.7 万元 通过结合受教育程度和薪资水平的数据特点来看,学历越高的人群中,月薪 1.7 万元以上的高收入比例越高。在一线城市(北京、上海、广州、深圳、天津)中,月薪超过 1.7 万元的开发者占比为 30%,该比例远高于国内其它城市。 开发者属于相对高薪的职业,尤其是在一线城市中,但不同开发者之间收入差距较大。软件开发是一个智力密集型的工作,不同开发者能够提供的价值差别很大,这就使得一个优秀开发者的收入远高于普通开发者:硕士和博士毕业的高收入者比率要远高于本科及以下的;金融和互联网行业的高收入比率最高。 自学是开发者持续学习的主要路径 软件开发行业日新月异,只有保持持续学习才能跟上技术变化的脚步,终身学习是现代人保持竞争力甚至是维持生存的必要手段。 从调研中可以看到,53% 的开发者会通过在未参加正式课程的情况下,自学一门新语言、框架或工具。但同时,也有半数的人参加过在职培训或者线下课程,相对于自学的灵活性而言,这类培训会更为系统和完整,对于长期的个人提升有所裨益,开发者可以适当选择。但与之相悖的是,只有不到 40% 的开发者,愿意为学习付费,这可能会导致参与的课程质量不够高。 Java 雄踞语言榜,Visual Studio 受开发者欢迎 Java 长盛:使用最多,开发者最想学 从编程语言来看,Java 是最多人使用的语言,而 JavaScript 和 SQL 分别是第二第三位。这三门语言,使用场景都很广泛,Java 一方面后端开发最常使用,生态成熟度无人可比;另一方面,Java 依然是 Android 上最重要的开发语言,与之相比 ,新兴的 Kotlin 只有 2% 的开发者在使用。而 JavaScript 不仅是前端开发的必备语言,还用在 Web 开发、小程序开发等场景下。 Java 和 Python 依然是开发者最希望学习的语言之一,只是相比之下,Python 的热度有所降低,这可能和机器学习没有去年那么火热有所关联。变化比较大的是 Go 语言,与去年相比,今年的调研中想学 Go 语言的开发者降低到了 4%,与之相似,Kotlin、R 的学习意愿也大幅降低。 从这个趋势也可以看到,如今的开发者更意愿去学习一些相对成熟度、用途更为广泛的语言,对一些代表新模式的语言乐衷程度有所降低。 七成以上在使用 Windows 操作系统,83% 在使用 MySQL 数据库 72% 开发者在使用 Windows 操作系统,18% 在使用 Linux 系列操作系统。在存储服务的使用上,MySQL 继续扩大其使用率到达了 83%,几乎是开发者必备的技能。和去年相比,Elasticsearch 出现在数据库使用的调研中,在大数据时代,Elasticsearch 作为提供搜索服务的第一选型,也必然会被越来越多的开发者学习和使用 Node.js 是相对使用普遍的技术框架 在 Web 开发上,前端使用 Vue.js 后端使用 Spring 是最常见的选型方案,与之相对应,Node.js 是最多被用到的框架,这和当今多端开发的趋势密不可分。后端用微服务架构,中间用 Node.js 粘合出适合 Web、Android、iOS 等不同端和场景使用的 APIs,是当下主流的部署方案之一,既可以前后端分离提高开发效率,又可以在保障服务稳定性的同时提升灵活性。而TensorFlow 成为开发者最期望学习的框架,这说明开发者依然对机器学习保持关注和热情。 Visual Studio 是最为普遍使用的开发环境 在开发环境的选择上,Visual Studio 是最为普遍使用的开发环境,这和微软对开发者的投入密不可分。微软投入了大量的研发力量,使得 Visual Studio 可以在各种操作系统进行各种编程语言的开发,其强大且完善的插件系统可以满足开发者的各种需求,使其可以超过 IntelliJ。 大数据平台以私有云部署为主,Spark 使用率高达 44% 私有云部署解决方案是企业构建大数据平台的主要方式 随着分布式计算和云平台的逐步成熟,目前大部分公司都有能力搭建自己的大数据平台。调研数据显示,81% 企业在进行大数据相关的开发和应用,50% 的企业选择私有云解决方案来部署大数据应用,28% 的企业选择自主研发。 仅 19% 企业使用商业发行版 Hadoop 版本搭建数据平台 调查报告发现,有 30% 以上的企业并没有使用相对成熟的 Hadoop 技术搭建数据平台,这些企业的算法性能会很大程度上受限于低效的平台,更不可能开发出更高效的数据分析算法。但幸运的是大部分企业都基于商业版或者社区版 Hadoop 搭建了数据平台,这些公司的侧重点主要在应用发现和算法的设计层面,更有可能在不久的将来实现大数据的价值。 Spark 是企业大数据平台最普遍的组件 Apache Spark 是一个处理大规模数据的快速通用引擎,它可以独立运行,也可以在 Hadoop、Mesos、云端运行,它可以访问各种数据源包括 HDFS、Cassandra、HBase 和 S3,可以提升 Hadoop 集群中的应用在内存和磁盘上的运行速度。Spark 生态系统中除了核心 API 之外,还包括其他附加库,可以为大数据分析和机器学习领域提供更多的能力。本次调研中,Spark 是使用最普遍的大数据平台组件,使用率达到44%,而MapReduce使用率仅为21%。 分布式文件系统 HDFS 作为核心组件之一,使用率也达到了 39%。企业对大数据平台应用最多的场景是统计分析、报表生成及数据可视化,38% 企业使用ELK(ElasticSearch + Logstash + Kibana)实时日志分析平台。 综上所述,目前大数据的发展热潮令人欢欣鼓舞。一个优秀的大数据团队,需要有对产品开发具有高敏感性同时对技术有一定理解的人才,同时需要理论基础极其扎实,能对实际问题进行抽象建模和算法设计的人才。只有双管齐下,在产品和技术方面进行深层次探索,才能真正实现大数据产业的繁荣。 区块链质变,比特币逆袭以太坊成 TOP 1 开发平台 22% 的开发者正在用或者准备用区块链技术解决技术问题 区块链技术的发展,是一个量变到质变的过程。相比于 2018 年,对区块链和加密货币了解的人从 22% 增长到 32%,准备尝试用区块链技术解决一些问题的人数从 14% 增长到 16%,仅有 4% 的人对区块链完全不了解。 43% 的受访者在从事公有链(比特币、以太坊等)的开发 本次调研中,43% 的受访者在从事公有链(比特币、以太坊等)的开发。目前行业侧重发展的方向为解决方案、公链及联盟链,公有链由于其自带激励机制,对于普通开发者有直接的回馈,所以上面开发者占比高也比较合情理。行业解决方案从去年的 27% 增加到今年的 36%,说明传统行业开发者对区块链的认可度在增加。 区块链本质上是技术,落地场景及实际应用才是连接社会效益的关键。 比特币和以太坊是当前两种主流的区块链开发平台 在行业开发者的印象中,以太坊一直是开发平台领域的头号玩家。但今年数据显示,以太坊从 2018 年的 44% 占比第一,降到 24%;比特币从 2018 年的 28%,上升到 35%,占比第一。比特币在行业内外仍然拥有最强共识,在闪电网络的加持下,大家也似乎感受到比特币离商用也不再遥远了。 金融是普遍认为的行业应用方向 金融行业是普遍认为的行业应用方向,占 36%。区块链本身具备的防篡改、可追溯的特点,能大大降低金融行业监管成本,不过金融的进入门槛相对也较高,需要各方面技术的配合。其次,智能硬件和物联网也被认为是主流应用方向,占 14%。不过相比其他众多已经很成熟的技术,依托区块链的解决方案在实际使用中,往往面临必要性缺失的问题,因此区块链应用发展仍任重道远。 在区块链结合行业之前,更加要重视与其他新技术的结合和协同:物联网设备能够提供大量数据,5G 能够提供高速传输,存储可以解决区块存放的问题等。 算法工程师最急缺,TensorFlow 占据 AI 深度学习框架榜首 64% 的企业尚未实现智能化 在经历了 2019 年的行业低谷期之后,无论是行业巨头还是新兴独角兽,都开始审视 AI 能够切实落地的场景。调研数据显示,14% 的企业尚无信息化基础,27% 的企业实现了事务处理数字化,22% 的企业具备商业智能基础设施,实现描述性分析。使用机器学习实现预测性分析和决策优化的企业占 16%,而在业务中全面使用 机器学习/深度学习算法工程师最急缺 在岗位分布上,由于深度学习是以大数据为基础的,而感知智能中的计算机视觉又是目前深度学习较为成熟的应用,所以,机器学习和深度学习工程师,以及数据工程师、计算机视觉工程师排行在前三位。当前最急缺的岗位也是机器学习/深度学习算法工程师、数据科学家/数据分析师/数据挖掘工程师岗位。 53% 的开发者表示其团队急缺机器学习/深度学习算法工程师,37% 表示急缺数据科学家/数据分析师/数据挖掘工程师。 TensorFlow是人工智能领域主流深度学习框架 此次调研中,TensorFlow 使用普及率达到 48%。从技术本身的角度来看,较为成熟的 TensorFlow 成为 AI 工程师的首选深度学习框架,Torch/PyTorch由于其开发效率较高,也得到了较多支持。 35% 开发者选用国产 AI 芯片应用于自己的 AI 开发 在 AI 芯片领域,国内厂商也开始弯道超车,越来越多的开发者也开始关注国内 AI 芯片的进展。调查数据显示,选用国产 AI 芯片应用于自己的 AI 开发时最看重的因素方面,对主流 AI 框架的支持能力是最普遍的因素,占 35%。 物联网云平台三足鼎立:阿里物联、华为云、百度 IoT 69% 的开发者认为未来 5G 网络的传输速率能达到 4G 的 10 倍以上 每一代新型的通信系统总是能带来更大的带宽。据报告显示,近七成开发者认为未来 5G 网络的传输速率能够达到 4G 网络的 10 倍以上。 影响 5G 普及的三大因素:5G 套餐价格未定、运营商的开发程度、需要更换手机 由于目前 5G 网络使用者较少,费用较低廉的套餐还没有推出,第一代 5G 终端不太成熟等原因,目前 87% 的开发者认为 5G 套餐费用过高,并且大部分开发者认为 5G 网络目前覆盖范围有限,因此将近 40% 的开发者正处于观望阶段。 值得一提的是,本次调查中 62% 的开发者认为,5G 时代应该加强对个人隐私的保护,这反映出目前社会对数据隐私越来越重视的整体趋势。 阿里物联和华为云是应用相对普遍的 IoT 云平台 根据调查,2019 年物联网云平台呈现三足鼎立的趋势:阿里物联、华为云、百度 IoT 成为用户最多的三种物联网平台,并且和第四名中移物联远远拉开了差距,这和我们的实际使用体验一致。 未来的基础物联网平台可能会继续呈现以偏硬件实现为主的华为云和以偏软件体验为主的阿里、百度物联平台的三足鼎立局面。 物联网技术开发:Linux 和 Windows 是使用较多的操作系统 Linux 和 Windows 是较普遍的操作系统,使用率分别为 51%、44%。目前在物联网设备开发过程中,Linux、Windows 和 Android 较为普遍,依然延续了 PC 平台的开发者操作系统份额。虽然华为、阿里等公司在 2019 年均发布了自己的物联网专用操作系统,但还并未得到开发者的大规模认可,大公司的物联网操作系统发展之路依然任重而道远。 Wi-Fi 是应用最普遍的物联网通信技术 在本次调研中,近距离通信(比如 Wi-Fi 和蓝牙)是现存物联网开发者最主要的通信方式。然而这种比重可能会随着未来 3~4 年内车联网的大规模商业化产生变化,汽车、工业物联、智能电网这类高移动性、高可靠和低延迟物联网场景会更适合需要整体规划的运营商网络。 六成开源开发者无收入,Apache 项目最受喜欢 77% 开发者每周在开源上投入时间不超过 5 小时 无论是大数据、区块链、人工智能还是物联网领域,其中最为重要的、最受欢迎的技术都是开源的。但是报告统计发现,有超过一半的开发者很少参与开源项目,每周在开源上投入不超过 5 小时的占 77%,其中,1 小时以内的占 31%。此外,65% 的开发者不曾在开源上获得收入,获得不错收入的仅占一成。 开发者最喜欢的开源项目是 Apache 25% 开发者最喜欢 Apache,24% 开发者最喜欢 Linux。作为全球最大的软件基金会,开发者用过的诸多项目,例如 Dubbo、Log4j、Maven、RocketMQ 和 Tomcat 等,均孵化自 Apache。 国内开源的现状虽然近年来已经有了很大的发展,但是一个残酷的事实是,老兵正在离开这个行业,离开一线开发的队伍:报告数据显示,30 岁以下的开发者人数超过 82%,接触开源的时间在 5 年以内的开发者超过 83%。随着那些经验丰富的老兵转行或是进入管理层,不再写代码、也不再参与开源的事实也就凸显出来.....未来开源的建设,依然任重而道远。 在数据中寻找共性,《2019 - 2020 中国开发者调查报告》全面且真实地展现中国开发者及技术现状,希望对您的学习或工作有所帮助。 ———————————————— 版权声明:本文为CSDN博主「CSDN资讯」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/csdnnews/article/details/104538091

问问小秘 2020-03-11 16:46:19 0 浏览量 回答数 0

问题

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

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

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

更多推荐

阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站