什么是微服务?阅读本文,正确认识微服务
微服务这个词已经在软件行业变的非常热门,不了解微服务已经不好意思说自己是IT行业的从业人员,笔者学习和践行微服务也有一段时间,看了很多人的文章和参与了很多讨论,每个人的理解和认识都存在差异,最近一次在机场等待的时机重读了Martin Fowler(微服务之父,他1999年的著作《重构》在编码界也是非常火爆,影响了很多从业者)的文章,收货满满,再结合最近几年的实践经验,对微服务的认识有了新的提高,对微服务的理解也更加深入。
正值新型冠状病毒肆虐,国务院延长了春节假期,可以抽时间总结分享出来,给需要的朋友。有条件的同学建议阅读https://www.martinfowler.com/articles/microservices.html的英文原文,这里是原汁原味的微服务理念介绍和经验分享,相信读者更能获益。
1.微服务的定义
在开始讨论之前,首先明确微服务是一种架构风格,一种开发方法。用来开发一个软件套件中的单个应用的方法;这种方法具有共同的特点,即——这单个的应用运行在独立的进程内,和其他应用采用轻量级的通信方式进行通信(通常是HTTP),这些单个应用程序围绕业务功能构建,独立的开发和完全自动化的部署;这些应用之间有最少限度的集中管理,可以采用不同的语言开发,不同的存储技术。
为了更好的理解微服务架构,先认识一下微服务流行之前的架构,这种架构我们称之为单体架构风格Monolithic,这种架构构建的应用程序整体作为一个单元,通常包含三部分即客户端界面程序、服务端应用程序和数据库。客户端用户界面包含HTML,CSS,Javascript等运行在浏览器的程序;数据库包含数据库的表,视图和存储过程等用以存储数据;服务端应用程序包含处理HTTP请求,处理业务逻辑和数据访问等,这个服务端的应用程序就是个单体应用,系统的任何改变都将牵涉到重新构建和部署服务端的一个新版本。
这种单体应用程序是最自然的构建系统的方式,所有请求的处理都到单体应用程序的进程内,采用应用程序开发语言的基本特性把它拆分成不同的包、类和函数中从而实现模块化,可以在开发者的便携机上开发和测试单体应用。可以采用部署流水线把测试后的应用程序部署到生产环境中,可以增加更多负载均衡器后面的实例数量来水平的扩展服务能力。
单体应用程序可以做的很好,但人们也越来越发现问题,尤其是把应用程序部署到云上以后。变更被捆绑在一起,单体应用程序中一个小的改变都需要整个程序重新部署,时间长了保持模块化的架构也会比较困难,本应影响一个模块的变更也很难做到仅影响单个模块。单个模块的伸缩需要整个程序来伸缩,这也导致需要更多的资源。这些问题就导致了人们自然而然地想到了微服务架构,把程序构建成一系列服务,每个服务可以独立部署和伸缩,每个服务也定义了清晰的边界,不同的服务可以采用不同的语言编写,不同的团队来维护。
下图来之martin fowler的官方网站,不同颜色和形状的色块代表了不同的功能,单体架构把所有的功能放在一个程序中,微服务将每个功能放入一个一个微服务中,单体架构需要整个程序部署多份以达到伸缩的目的,而单体应用可以根据功能的使用情况再伸缩。
正是单体架构的这些问题,才使得微服务风格的架构得以发展,微服务除了服务是可独立部署、可独立扩展的之外,每个服务都提供一个固定的模块边界。甚至允许不同的服务用不同的的语言开发,由不同的团队管理。下面文章探讨一下微服务所具有的共同特征。
2.微服务架构的特征
微服务之父也无法给出微服务架构风格的一个正式定义,但他尝试去描述该架构的一些共性。就这些共性来说,并非所有的微服务都具有这些共性,但我们期望大多数微服务都具备大多数特性。
2.1 通过服务的方式组件化
在软件开发行业,长期以来都渴望通过插拔、物理世界堆积木的方式实现组件化,最近这几十年各种语言通过库的方式已经有很大的进步,一些语言也一定程度地实现了可插拔的模块化库。在讨论组件化的时候,不可避免的回到一个问题,什么是组件化,它的定义是什么?我们对组件化的定义是可以独立替换和升级的软件包。
微服务架构也会使用到现代编程语言提供的各种类库,但微服务实现组件化的方式是把业务拆分成不同的服务来实现的。我们把库定义为链接到程序并使用内存函数调用的组件,而服务是一种进程外的组件,它通过WEB服务请求或RPC(远程过程调用)机制来通信。
我们使用微服务做为组件化的原因是微服务可以独立的部署,如果你的应用程序在一个进程内包含了多个库作为组件,这些组件中的任何一个变化都需要整个应用程序重新部署。如果是以微服务的方式实现组件化,那么仅对实现变化的这些微服务重新部署就可以了,不需要整个应用重新部署。当然这也不是绝对的,一些变更将会导致服务接口变化,这样就导致多个服务发生变化,但一个好的微服务架构的目的是通过高内聚和按接口契约演进机制来最小化变更。可见微服务和库的很大一个区别就是是否可以单独部署。
用微服务来实现组件化的一个另一个好处是,微服务之间有清晰的服务接口定义;大多数语言没有没有提供定义发布接口的能力,只能通过文档和原则来约定,这就导致调用方很容易浸入到被调用的内部或者具体实现上去,从而造成了过度耦合(例如JAVA的JAR包,我们提倡面向接口编程,但调用方也可以直接构造实现类);微服务的接口定义方式很好的解决了这一问题,调用方只能通过远程调用的方式访问服务提供者,不可能侵入到被调用方的内部。 微服务的这种调用方式也有副作用,远程的调用比进程内通信代价要高很多,因此微服务的调用方式接口粒度要比进程内调用粒度粗,也即一个请求尽可能多的获取到所需的信息,而不是像进程内调用那样,需要的时候获取一小部分信息。
2.2 围绕业务能力划分微服务
当想要把大型应用程序拆分开时,通常聚焦在技术层面,导致划分出UI团队、服务侧团队、数据库团队的划分。当团队按这些技术线路划分时,即使是简单的更改也会导致跨团队的协调。按照这个划分,有新需求UI团队会把逻辑放到UI层,服务器团队会放到服务器层。这就导致逻辑无处不在,这是康威法则在起作用的一个例子。
有什么样的组织结构,就会有什么样的软件架构--- Melvyn Conway, 1967
而微服务的方式划分是不同的,围绕业务能力划分成不同的微服务,一个组织部门内部包含1到多个微服务,这些微服务里面包含了全面的用来实现这些微服务技术栈的人员,包含UI、服务器和数据库存储人员。这样的一个团队是跨技术栈团队,这个团队的成员能完成微服务的前后台开发、数据库开发及项目管理。
如下图所示,左边的图是微服务团队,团队里面包含了微服务所需的技术人才,有UI、服务器和数据库等,而围绕技术能力划分的团队,将团队划分为UI团队、服务器团队和数据库团队。
这里提到的微服务团队,很自然的问题是微服务团队应该由多大,这里实际上并没有一个清晰的定义,但根据业界实践,亚马逊建议最大不超过2个披萨,也即1个团队2个披萨能够喂饱,也意味着这个团队大小不超过12个人,也有的团队6个微服务用6个人来维护,也即1个人1个微服务,这样的粒度无疑太细了,我们不建议太细,但再大也不建议超过12个人。
2.3 做产品而不是做项目
产品和项目的最大区别在于项目是一次性的,目标是交付软件,完成后的软件被交接给维护组织,然后它的开发团队就去干别的事情了,或者说压根解散了,而产品是长期演进的,是不断迭代演化的。微服务更倾向于避免项目的模式,而是以产品的模式来运作,一个团队负责产品的整个生命周期。
亚马逊的理念 “you build, you run it” ,即谁开发谁维护,开发团队负责软件的整个产品周期。这使开发者经常接触他们的软件在生产环境如何工作,并增加与他们用户的联系,因为他们必须承担至少部分的支持工作。
这样的“产品”理念,是与业务功能的联动绑定在一起的。它不会将软件看作是一个待开发的功能集合,而是认为这是一个持续迭代的、发展和演进的产品,即软件如何能助其客户来持续增进业务功能。
2.4 智能端点和哑管道
在传统的SOA架构下,在不同的服务之间通信时,采用的方法是在其通信机制上增加了很多智能化,增加了不少业务逻辑处理。一个典型的例子就是ESB(Enterprise Service Bus), ESB 往往包含很多高级的功能,比如消息路由、编排、消息转化、和业务规则处理。
而微服务的则往往采用另一种替代方法,智能的端点和哑管道,也即微服务在通信管道上不处理业务逻辑,仅作为通信方式存在,业务逻辑在通信双方的微服务上处理。构建成微服务的目的是要做到高内聚和低耦合,每个微服务拥有自己的领域逻辑,而且很像是UNIX的过滤器那样工作,接受一个输入请求,对其应用业务逻辑,并产生一个响应。这些微服务之间通信,更倾向于采用简单的RESTFUL风格协议而不是复杂的协议(如基于SOAP的web service,或者BPEL)。
微服务和十几年前的SOA架构看起来非常相似,很多理念也很类似,但本质上有很大差异,SOA架构通常都有一个庞大、复杂的ESB总线,各个单体应用之间通过ESB来交换数据,ESB也承担了很多业务逻辑转换和处理的工作,但在微服务概念里面,没有ESB,有的只是轻量级的消息通信机制。
微服务建议采用2种方式来通信,一个是HTTP请求-响应式的API,第二个者轻量级的消息中间件通信。第一种HTTP方式,正是构建万维网使用的协议,通常使用的资源很容易被缓存起来。第二种方式是通过轻量级消息中间件来通信,比较常见的是RabbitMQ, ZeroMQ, Kafka等,这类消息中间件仅提供一个可靠的异步通信机制,不提供额外的功能,这也就是哑管道,而智能部分在端点侧,也就是通信双方微服务。
在单体应用中,组件之间通过内存中进程内的方法调用或者函数调用完成,把单体应用拆分为微服务架构的最大问题就是通信方式的变化。简单的把进程内的方法调用转换为RPC调用是十分错误的,因为在进程内调用开销非常小,获取的信息的粒度非常小,可以非常频繁的通信,但转换为微服务之间的调用之后,就要切回为更大粒度的通信了。 例如:单体应用里面订单信息和顾客信息在一个应用内,订单需要姓名,则调用订单模块的getName接口获取,需要地址信息再调用getAddressInfo接口获取,但拆分成微服务之后,就不能这么频繁的调用,顾客信息应该提供一个粗粒度的接口给订单管理,一次性提供顾客相关的姓名、地址信息。
2.5 去中心化治理
中心化治理带来的结果是趋向于标准化到单一的技术、工具、方法和流程,经验显示这种方法限制太多了,不是所有的问题都是钉子,也不是所有的解决办法都是锤子,多样性的世界和多样性的业务更趋向于不同的事情采用不同的工具,虽然单体应用也可以这么做,但这在单体应用中并不常见。
在将单体应用拆分成微服务时,可以根据业务特点和需要选择合适的技术,报表页面就用个简单的Node.js,当然可以,实时处理的需要用C++,当然也可以,想采用特定类型的数据库来提高读取性能,当然也没有问题。这里仅仅是说可以这么做,但不代表应该这么做。拆分成微服务后,不限制每个微服务采用的技术,但作为整个团队的一部分,技术还是应该尽可能的统一。
采用微服务的方式不是说就没有标准要遵守了,微服务的标准不是定义一堆预先选定的技术,而是微服务开发风格。大家共同的标准就是遵从微服务风格。每个微服务团队更倾向于采用对开发有利的工具,这些工具可以给其他团队用,当在解决问题时,也是优先采用已有的工具,可能来自于公司内部的开源,也可能来自于互联网开源。Netflix就是采用此哲学的很好的例子, 他们共享有用的,完整测试的代码,把这些代码作为库共享出来,鼓励其他开发者用这些库来解决问题,当然也鼓励开发者采用其他的方式来更好的解决。
对微服务社区而言,大家不愿意消耗太多的时间去做服务契约的管理,这不是说不重视服务契约,相反,非常重视服务的契约,有不同的方法来探索和尝试管理服务契约。如Tolerant Reader和消费者驱动型契约模式经常应用到微服务。这些模式有助于服务契约独立进化。采用消费者驱动服务契约的方式不但可以给服务团队增加信心,也能快速获得微服务是否工作正常反馈的良好方式。有的团队,先定义服务契约,之后再基于契约自动生成编码骨架,开发团队负责实现这些服务,不少团队采用这种方法,效果不错。
可能去中心化的最高境界就是亚马逊提倡的“谁开发,谁维护”的理念,开发团队负责软件的方方面面,包含安装和运维,这种模式确实很难达到,因为这会造成组织结构的重大调整,一些岗位的消失,开发团队的压力变大,这必然会带来阻力,但越来越多的公司正在这么做,或者走在这么做的路上,典型的就是亚马逊和 NETFLIX; 这种模式给开发团队的压力(晚上3点中被叫起来处理问题),才会促进开发团队注重代码的质量。这种模式和传统的开发团队开发、运维团队运维想去甚远。
2.6去中心化的数据管理
去中心化的数据管理通过几个方面表现出来:
(1)最抽象的层次是系统之间的概念模型不同,这会在大企业的系统集成带来问题,销售眼中的客户和技术支持眼中的客户是不同的,一些销售眼中看到的属性,在技术支持眼中可能完全没有,即使出现也可能具有不同的属性,或者(更糟糕的)属性相同,但语义却有细微的差别。 这个问题在单体应用之间很常见,在应用内部也时常发生,特别是应用被划分为多个模块的时候,一个有用的方法是采用领域驱动模型DDD,DDD是把一个复杂的领域划分为多个有边界的上下文,然后在这些有界上下文上做映射,这个方法对单体应用和微服务都有用,只是DDD划分的边界和微服务更为贴合。
(2)除了上述的概念模型去中心化,数据存储也去中心化,如下图所示,单体应用倾向于采用单一的数据存储技术,比如Oracle来存储数据,而微服务让每个微服务自己管理自己的数据,因此各个微服务采用的数据存储技术也可以相差很大,各自管理各自的数据,采用多数据库来管理各自的数据。
去中心化的数据管理对微服务的数据更新有较大影响,在单体应用中,跨越多个资源的数据更新用数据库的事务就可以保证一致性,但在微服务领域,由于每个微服务都单独管理自己的数据库,数据库采用的管理软件,存储方式都不一样,所以这是一个很大的难点,分布式事务实现起来难度很大,带来了很多的额外的复杂度,因此微服务架构强调使用没有事务的微服务之间的协调机制,这种方式明确的提出一致性只能是最终一致性来保证,可能产生的问题只能通过补偿机制来完成。
这种去中心带来的不一致问题会给开发团队带来很大的挑战,但这也是最符合实际的业务实质。在实际的业务处理中为了快速应对需求也会有一些不一致,往往通过逆向的流程来处理。只要处理这种错误的代价小于强一致性带来的业务损失,这种取舍就是值得的。
2.7 基础设施自动化
基础设施自动化在过去几年有了长足的发展,云计算的发展简化了构建、部署和维护微服务的复杂度。很多产品和系统通过持续集成和持续交付构建,采用这些方法的团队极大的利用了基础设施自动化,下面这张图展示了构建流水线的过程。
单体应用能够用持续集成和持续交付流程快速的部署到生产环境,只要单体应用完成了这种自动化构建,部署多个微服务也不会更复杂,无非是单体应用是单个少量的应用,但微服务是多个应用,1个和多个之间没有太大的区别。
2.8 失效设计
采用微服务这种设计风格,应用本身就应该被设计成能容忍失效,任何服务调用都有可能因为目标服务不可用而失效,调用方必须能够尽可能优雅的处理,从这一点上来说,这相比单体应用引入了额外的复杂性。所以微服务团队要考虑微服务的失效,如何影响到用户体验。Netflix 通过自生产环境里面注入微服务、数据中心故障来测试应用的韧性和应用的监控能力。这种一周繁忙工作结束后在生产环境的自动化测试足以让很多的开发团队不寒而栗,需要很强大的勇气和技术实力作为保障。
当然这不是说单体架构就不能做这种类型的失效设计,只是不像微服务架构风格这么常见。因为微服务可能在任何时候失效,所以快速的发现这些失效的微服务,并恢复它们(如果可能)至关重要。微服务架构在服务的监控上需要花费更多的精力,需要监控架构指标(如数据库每分钟处理多少请求)和业务指标(每分钟接收到多少订单),这种指标层面的监控可以给开发团队告警,从而让开发团队去跟进和调查。这种微服务的监控,在单体应用的设计中可以而且也应该被监控记录下来,但单体应用往往在单个进程里面,因此某个单体应用中的组件,连接不上、失效的价值就没有微服务这么大了。
现在越来越多的更高级的监控工具和日志工具已经被开发出来,很多是开源使用的,在这些监控工具下,可以在管理面板上看到各个微服务的运行状态、吞吐量和业务指标,熔断状态、延迟等我们关注的一系列指标。
2.9 演进式设计
微服务的实践者,通常具有演进式的设计思路,把服务拆分作为一种工具来控制变更,而不是降低变更的速度。控制变更不是说减少变更,用正确的工具和态度,不但可以频繁、快速的,而且可以良好的控制变更。
如论什么时候,开始拆分系统的时候,都面临如何划分的问题,这里一个简单的原则即可了独立替换、可独立升级原则,这也就说我们可以重写整个微服务而不用影响微服务之间的协作。事实上有的团队更进一步,认为服务从长远来看更倾向于走向消亡而不是长期演进。
英国卫报网站是一个单体应用向微服务演进很好的例子,单体应用还是网站的核心部分,但新增加的功能和特性就采用微服务调用单体API的方式实现,这种方式对一些天生就是临时性的服务特别有用,比如处理某个体育时间的专题页,这种一次性的专题页,可以通过快速开发的方式,采用快速开发语言开发出一些服务出来,在事件结束后再废弃掉。这种方式在财经机构的服务里面也很常见,快速的开发出服务,几个月以后再废弃掉。
这里强调可替换性,是更通用的模块化设计的一个特殊场景,我们总应该让变更同一个时间发生在一个模块内部,不希望是跨越多个模块的,如果你发现两个服务总是同时一起改动,那么这就是这两个微服务应该合并的信号。把组件组合成一个服务可以形成更粗粒度的版本发布计划,单体应用需要整个应用全部的构建和发布一遍,但微服务架构风格下,仅需要构建和替换修改的这个微服务,这可以简化和加速发布过程,缺点是不得不考虑单个服务升级对服务的调用方的影响,传统的做法是采用版本的概念来管理,但在微服务架构风格下,版本仅作为最后不得已的手段,我们在设计微服务时,应该尽可能的考虑能容忍被调用方的变化。
2.10 微服务是未来的主流趋势吗
微服务是未来的主流趋势吗,这个问题没有人能给出确定的答案,文章本身也是聚焦在阐述微服务的主要特点以及和单体应用的不同,就连微服务之父也不能确定的说微服务就是未来的主流趋势,他也承认需要更多的时间来观察,尽管当前微服务带给我们的积极的正向的影响要多于负面的影响,但可以肯定的是微服务是当前重要的一种架构风格,值得我们去深刻考虑和投资,有一些先驱已经践行这种风格,并且应用的非常成功,国外的比如亚马逊、Netflix、英国卫报、英国*等,国内的阿里巴巴、腾讯、网易、以及笔者供职的华为也都大量的采用了微服务这种架构风格,还有很多的这样的企业正在是使用这种风格的架构来构建自己的企业IT系统。
上一篇: 微前端理念
下一篇: 传奇 GOM 引擎微端设置教程
推荐阅读
-
企业微信服务商是什么?有哪些实用功能?
-
什么是微服务?阅读本文,正确认识微服务
-
搜狗微信为什么搜不到服务器,搜狗微信搜索平台公众号(订阅号和文章内容独家收录方法)...
-
智联招聘发布第三季度平均薪酬报告;价值13亿美元的Metaverse日活跃用户仅38人;统一充电接口或让苹果一年损失数百亿美元 | EA周报 - 热点大事件 微信推出刷掌付小程序,开启全新支付模式 据悉,微信已上线 "微信刷掌付 "小程序,可以为用户刷掌付增加更便捷的管理方式,但刷掌付功能需要在刷掌设备上开通。刷掌付是继密码支付、指纹支付、刷脸支付之后,微信的又一新型支付方式。据悉,目前微信支付已在深圳部分商户接入刷掌付设备进行测试,用户可通过刷掌纹支付订单。刷掌纹设备由微信支付提供,设备上设有显示屏和掌纹识别区,用户开通微信刷掌纹支付功能后,只需在掌纹识别区扫描,即可完成商品支付,相比传统的密码支付和指纹支付,更加便捷。(星球科技) 微软多项云服务落户中国新数据中心 2022年10月13日,微软年度技术大会Ignite 2022和Ignite China中国技术峰会同步开启在线直播。面对中国市场日益增长的客户需求,微软宣布,Azure、Dynamics Power Platform等多项服务已在北上广三地数据中心落地,提升在中国市场的服务能力;世纪互联运营的Office 365上的Teams服务和世纪互联运营的Microsoft 365服务将于2023年上半年正式上线,为中国市场带来更全面、更优质的本地化服务体验和技术保障。 IBM宣布将红帽存储并入存储业务部 根据IBM与红帽的协议,IBM将成为Ceph基金会的主要赞助商,该基金会的成员合作推动Ceph开源项目的创新、开发、营销和社区活动。红帽OpenStack客户仍可从红帽及其合作伙伴处购买红帽Ceph存储,而拥有现有订购服务的红帽OpenShift和红帽OpenStack客户将能够在不改变与红帽关系的情况下,根据需要维护和扩展其存储足迹。 扎克伯格谈新款1万美元VR头显:成本价,我们不会像苹果那样定高价 元CEO扎克伯格在接受采访时谈到了公司新发布的Quest Pro新款VR头显的价格,他表示1499.99美元的定价只是 "性价比",让更多人通过购买硬件来体验元宇宙。扎克伯格还借此机会挖苦了竞争对手苹果公司,称苹果公司对该设备的定价 "已经到了极限"。他说:"通常,人们制造硬件,然后想从中获利。例如,苹果公司就是这样做的,制造硬件,然后尽可能多地收费。他说,公司还计划推出 Quest 3,售价在 300 美元到 500 美元之间。 智联招聘发布招聘薪资报告,第三季度全国平均薪资为10168美元/月
-
《京沪公园使用大数据报告》解读城市公园新机遇-Part One 公园基本情况 1 城市公园分布 城市公园分布广泛,主要集中在中心城区和郊区的居住密集区 根据公开数据,北京市注册公园数为403个(2016年),上海市为165个(2015年)。基于腾讯地图,找到京沪两地所有公园的位置点信息,将它们画在地图上,可以发现,城市公园分布广泛,并且主要集中在中心城区和郊区的居住密集区。 公园数量数据来源:北京-《瞭望东方周刊》,上海-2016年上海市统计年鉴; 公园位置点信息来源:腾讯地图POI数据; 2 人均公园绿地面积 北京北部、上海东北部人均公园绿地面积较多 数据显示,截至2015年年末,北京的人均公园绿地面积为13.6平方米/人,上海则为7.6平方米/人。从各区人均公园绿地面积的数据可以看出,受区域面积和人口数量的双重制约,城市中心区的人均公园绿地面积通常较小。北京人均公园绿地面积较多的地区主要是在北部,而上海则是在东北部。 数据来源:北京市园林局网站,2016年上海市统计年鉴 Part Two 公园受欢迎程度 1 网络热度 哪些公园是“网红”? 樱花季促成玉渊潭公园和顾村公园最热! 根据腾讯位置大数据,春季时,在我们选取的几个公园中,用户通过社交分享最多的公园,北京是玉渊潭公园,上海是顾村公园。这两个公园的热度远远领先其他公园,成为当之无愧的“网红”公园。玉渊潭公园和顾村公园在春季都有樱花节活动,京沪两地的植物园在春季也有较高的网络热度。 注:社交分享包括微信朋友圈、QQzone等社交工具中的签到信息 2 公园吸引力程度 公园有多吸引人? 部分大型公园超50%的游客来源于10公里外 公园的吸引力可以用到访者居住地到公园的直线距离的中位数来衡量。根据腾讯位置大数据分析,京沪两地都是知名公园吸引力较大。以北京颐和园和上海辰山植物园为例,50%的游客来源于20.3公里和17.6公里以外。热度最高的北京玉渊潭公园和上海顾村公园也有较高的吸引力。 3 外地游客比例 只有知名公园有外地游客? 社区公园仍有5~10%的外地游客到访 颐和园作为全国景点,毫不意外,外地游客比例高达40%,远超京沪其他公园。上海的公园中,人民公园的外地游客比例达到19%,可能与其临近旅游热点南京路和人民广场有关。总的来说,本身就是景点或临近人群聚集地的公园外地游客比例高。通常意义上社区公园主要服务于当地居民,而数据显示,京沪的社区公园仍有5~10%的外地游客到访。 Part Three 公园使用情况 1 工作日和周末人流量对比 北京奥林匹克森林公园超200%, 上海辰山植物园周末游客增幅达170% 大型的综合公园、主题公园、郊区公园周末人流量都有至少50%的增长,北京的奥林匹克森林公园、南海子郊野公园,上海的辰山植物园、顾村公园,周末游客增幅达到了100%以上。一些距离工作区较近的公园如上海陆家嘴中心广场公园、北京CBD历史文化公园,周末时人流量则出现了明显下降。 2 人流量随时间变化 上海的周末人流高峰期更晚更集中 上海中心型公园、主题型公园和郊区公园的高峰期在周末更为集中,并会发生明显推迟,到14~15点才达到人流量高峰。而北京的公园在上午10~12点期间就进入了高峰期,在15~16点也有一个高峰期。 Part Four 位置大数据带来的启示 1 建立合理的公园体系结构 丰富体系结构:大型公园和小微公园结合,优化空间利用率 公园的使用情况可以用空间利用效率衡量,即“到访人数/公园面积” 。从数据来看,京沪两地空间利用效率高的公园都是中小型公园,而大型公园的空间利用效率则较低; 考虑到安全、环境等管理成本,大型公园多采取收费、围合等管理模式,这会降低公园的空间利用率,可进一步研究费用高低、范围设定和利用率的关系,优化空间利用率; 合理的城市公园体系还需要与就业中心结合的公园以及服务社区的公园。在空间资源日益紧张的大城市,除了在郊区新建大型公园外,在城市中心区新建更多的微型、小型公园也是不错的选择。 2 混搭多种功能区域 混搭区域功能:城市公园选址宜与多种功能区域搭配,关注慢行设施 城市公园可以和工作区、商圈、公共活动区等多种区域相结合。公园在工作日可服务于区域就业、商务人士,在周末也可以服务市民休闲和社会活动。有利于凝聚人气,更大地发挥公园的功能。如上海的徐家汇公园,周边是写字楼聚集区,又是商圈,同时又有大量居民区,周末的空间利用效率相比于工作日反升8%;。 关注公园周边慢行设施的设计,方便游客步行到达。结合热力图和三维地图可以看出,徐家汇公园东西两侧的汇金广场、港汇广场、徐家汇国际大厦、宛平宾馆、上海财政局等是公园使用者集聚程度最高的地区。五洲国际广场、均瑶国际广场虽然距离较远,但是沿肇嘉浜路到徐家汇公园较为便捷,也在步行范围内,所以也同样具有较高互动性。可见便利的慢行设施可以增强公园和周边的互动。 3 位置大数据优化公园服务 优化公园服务:根据到访人群来源判断服务偏向,提供精准服务 通过位置大数据,可以识别出公园的服务偏向,判断公园的使用是否符合预期,及时优化公园内部及周边服务设施。服务偏向可以根据到访过公园的游客工作或居住在公园周边2公里内的占比判断。如北京的北小河公园、上海的彭浦公园等服务周边的居住人群更多,这些公园可以考虑多配备小广场、健身器材、儿童游乐场等设施;而北京的CBD历史文化公园、上海的西康公园服务工作人群更多,则可以考虑多进行绿化并配备长椅等休闲设施。 4 位置大数据助力公园管理 助力公园管理:位置大数据提供精准宣传和功能评估依据 在“互联网+”日益发达的今天,位置大数据可以帮助有意发展旅游产业的城市公园:
-
服务小微走在前列,江苏银行的制胜密码是什么?
-
微信 "扫一扫 "物联网,全面揭秘 "扫一扫 "背后的扫盲技术!-1.1 扫一扫感知物体是做什么的? 1.1 微信扫一扫是做什么的? 扫一扫识物是指以图片或视频(商品图片:鞋/包/美妆/服饰/家电/玩具/图书/食品/珠宝/家具/其他商品)为输入媒介,挖掘微信内容生态中的有价值信息(电商+百科+资讯,如图1所示),并展示给用户。这里的电商基本涵盖了微信小程序覆盖上亿SKU的全量优质电商,可以支持用户货比N家并直接下单购买,百科和资讯则聚合了微信内的头部自媒体如搜狗、搜搜、百度等,向用户展示和分享拍摄商品相关的内容资讯。 图 1 扫一扫识别功能示意图 欢迎大家更新iOS新版微信→扫一扫→识货,亲自体验,也欢迎大家通过识货界面的反馈按钮向我们提交反馈意见。 扫一扫识物实景图展示 1.2 扫一扫识物有哪些使用场景? 扫一扫识物的目的是为用户访问微信内部生态内容开辟一个新窗口,以用户扫图片为输入形式,为用户提供微信生态内容中的百科、资讯、电商等作为展示页面。除了用户熟悉的扫一扫操作外,我们还将进一步拓展长按操作,让用户更方便地进行扫一扫操作。"扫一扫知事 "的落地场景主要涵盖三大部分: a. 科普知识: a.科普知识。用户通过扫一扫,可以在微信生态圈中获取该对象的百科、资讯等常识或趣闻,帮助用户更好地了解该对象; b.购物场景。同样的搜索功能支持用户看到喜欢的商品立即检索到微信小程序电商中的同款商品,支持用户即扫即购; c.广告场景。扫一扫识别物体可以辅助公众号文章、视频更好地理解其中蕴含的图片信息,从而更好地投放匹配广告,提高点击率。 1.3 Sweep Sense 为 Sweep 家族带来了哪些新技术? 对于扫一扫来说,大家耳熟能详的应该就是扫一扫二维码、扫一扫小程序码、扫一扫条形码、扫一扫翻译了。无论是各种形式的编码还是文字字符,都可以看作是图片的一种特定编码形式,而物的识别则是对自然场景图片的识别,这对于扫一扫家族来说是一个质的飞跃,我们希望从物的识别入手,进一步拓展扫一扫对自然场景图片的理解能力,比如扫酒、扫车、扫植物、扫人脸等服务,如下图3所示。 图 3 Sweep 家族
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。
-
你知道什么是微前端吗?微前端与微服务有什么关系?
-
传奇微端是什么意思?传奇微端服务器配置要求--稳定、快速