
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 随着疫情持续蔓延,在家远程工作的员工规模不断增长,许多企业正在考虑将其业务向边缘迁移,并确保其数据量和安全性。 当年大型机开始投入使用时,对大多数公司来说,采用成本过高的大型机是通过分时服务共享的,并使用多用户系统集中处理。 在此之后又出现了微型计算机、个人电脑和局域网,人们把工作负载转移到个人电脑工作站和更小的计算平台上,并看到了计算分散化趋势。如今采用公共云这种超大规模解决方案处理数据,而这一次使用的是多租户方法。 如今,随着边缘计算的兴起,人们也正在再次考虑采用分散化计算技术。行业专家建议采用边缘计算技术,可以减少延迟并在本地存储数据。冠状病毒疫情如今将员工和流程推向一种高度分散的模式,边缘计算将成为技术前沿和中心,可以与云计算技术并驾齐驱。 一些边缘计算模式正在出现。第一种模式是直接在物联网设备上处理数据,例如恒温器或自动驾驶车辆。其模式称之为“面向设备”。第二种模式是使用一些广泛地理分布的计算平台,例如多个客户机(通常是工作站)。其模式称之为“面向边缘的服务器”。 对于正在考虑疫情结束之后处理业务的企业而言,第二种模式显然更具吸引力。它也是边缘计算模型的最新用途,并具有两种不同的类型:使用由公共云提供商提供的专有边缘设备,以及使用位于地理广泛分布的小型数据中心、办公楼甚至家庭中的私有服务器。 在转向边缘计算模式时,大多数企业需要注意一些问题,其中包括: 安全性。考虑到必须在客户端工作站以及云中保护数据的安全,边缘计算架构增加了复杂性,其中一些架构还添加了需要安全性的中间服务器。除了专注于保护单个公共云中的数据安全之外,还要致力保护存储数据的多个系统上的信息。 数据量。当添加低功耗的分布式计算平台时,其数据量可能使其不堪重负。内置自动数据库扩展功能的公共云存储系统几乎可以处理任何数量的数据。对于边缘计算服务器或客户端工作站来说,情况并非如此。 这并不是说边缘计算在疫情结束之后不能成为云迁移之后的重点,而企业需要了解一些可能面临的问题。 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/live 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间:2020-07-01本文作者:David Linthicum本文来自:“51cto”,了解相关信息可以关注“51cto”
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 使用 Spring cloud Gateway 构建微服务网关 Spring Cloud Gateway 是 Spring Cloud 的一个子项目,该项目是基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。 Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关,目标是替代 Netflix Zuul,其不仅提供统一的路由方式,并且基于 Filter 的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。 相关概念 Route(路由):网关的基本构件块,类似于 nginx 的 location 配置。由一个 ID、一个目标 URI、一组 Predicate 和一组 Filter 定义 Predicate(断言):路由组成的一部分,主要负责路由的匹配,来决定此次请求是否匹配路由,我们可以使用它匹配来自 HTTP 请求的任何内容,比如路径、参数或者 header 信息等等 Filter(过滤器):这个是 GatewayFilter 的实例,请求经过 Predicate 匹配路由之后执行 Filter,我们可以使用它修改请求和响应。 快速上手 Spring Cloud Gateway 网关路由有两种配置方式: 通过配置文件配置 通过 @Bean 自定义 RouteLocator 去配置 这两种方式是等价的,建议使用配置文件配置。因为 Spring Cloud Gateway 使用响应式编程框架,学习曲线相对陡峭。 引入依赖: <properties> <java.version>1.8</java.version> <!-- springcloud 版本 --> <spring-cloud.version>Hoxton.SR1</spring-cloud.version> </properties> <dependencies> <!-- 服务注册发现相关 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <!-- gateway 依赖 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency> </dependencies> Spring cloud gateway 是使用 netty+webflux 实现,因此不需要再引入 web 模块。 配置文件: server: port: 8088 eureka: client: serviceUrl: # 注册中心地址 defaultZone: http://dev-crm-host001.ymt.io:8761/eureka spring: application: name: test-gateway cloud: gateway: routes: - id: test1 uri: http://www.baidu.com predicates: - Path=/baidu/** filters: - StripPrefix=1 各字段含义如下: id:我们自定义的路由 ID,保持唯一 uri:目标服务地址,大部分场景我们是转发到某个服务上,配置 uri: lb://user-service 意思是请求要转发到注册中心的 user-service 服务上。 predicates:路由条件,接受一个参数,返回一个布尔结果决定是否匹配。Gateway 为我们内置了多种路由条件,包括 Path、Cookie、Param、Header、Before、After 等等,开箱即用,当然我们也可以自己实现 predicates filters:过滤规则,当请求经过 predicate 匹配成功后,执行 filter,我们可以使用它修改请求和响应,示例表示目标服务收到的 path 将无第一级。 启动程序,当我们访问 localhost:8088/baidu 时,gateway 会根据我们配置的路由规则转发到 https://www.baidu.com 路由规则:Predicate 介绍 Spring Cloud Gateway 的功能很强大,我们仅仅通过 Predicates 的设计就可以看出来,前面我们只是使用了 predicates 进行了简单的条件匹配,Spring Cloud Gateway 内置了很多 Predicates 工厂,这些 Predicates 工厂通过不同的 HTTP 请求参数来匹配,多个 Predicates 工厂可以组合使用。 网上有一张图总结了 Spring Cloud 内置的集中 Predicate: 说白了 Predicate 就是实现了一组匹配规则,方便让请求过来找到对应的 Route 进行处理。接下来介绍一下内置几种 Predicate 的使用。 通过时间匹配 Predicate 支持设置一个时间,在请求进行转发的时候,可以通过判断在这个时间之前或者之后进行转发。比如我们现在设置只有在 2020 年 1 月 1 日才会转发到 https://www.baidu.com/,在这之前不进行转发,我就可以这样配置: spring: cloud: gateway: routes: - id: time_route uri: http://www.baidu.com predicates: - After=2020-01-01T01:01:01+08:00[Asia/Shanghai] Spring 是通过 ZonedDateTime 来对时间进行的对比,ZonedDateTime 是 Java 8 中日期时间功能里,用于表示带时区的日期与时间信息的类,ZonedDateTime 支持通过时区来设置时间,中国的时区是:Asia/Shanghai。 Before Predicate 刚好相反,在某个时间之前的请求的请求都进行转发。我们把上面路由规则中的 After 改为 Before,如下: spring: cloud: gateway: routes: - id: time_route uri: http://www.baidu.com predicates: - Before=2020-01-01T01:01:01+08:00[Asia/Shanghai] 就表示在这个时间之前可以进行路由,在这时间之后停止路由。 除过在时间之前或者之后外,Gateway 还支持限制路由请求在某一个时间段范围内,可以使用 Between Predicate 来实现。 spring: cloud: gateway: routes: - id: after_route uri: http://www.baidu.com predicates: - Between=2019-01-01T01:01:01+08:00[Asia/Shanghai], 2020-01-01T01:01:01+08:00[Asia/Shanghai] 通过 Cookie 匹配 Cookie Route Predicate 可以接收两个参数,一个是 Cookie name,一个是正则表达式。 spring: cloud: gateway: routes: - id: cookie_route uri: http://www.baidu.com predicates: - Cookie=name, ymt 通过 Header 属性匹配 Header Route Predicate 和 Cookie Route Predicate 一样,也是接收 2 个参数,一个 header 中属性名称和一个正则表达式。 spring: cloud: gateway: routes: - id: header_route uri: http://www.baidu.com predicates: - Header=name, ymt 通过 Host 匹配 spring: cloud: gateway: routes: - id: host_route uri: http://www.baidu.com predicates: - Host=**.baidu.com 通过 Request Method 匹配 可以通过是 POST、GET、PUT、DELETE 等不同的请求方式来进行路由。 spring: cloud: gateway: routes: - id: method_route uri: http://www.baidu.com predicates: - Method=GET 通过请求路径匹配 之前示例是使用的请求路径去匹配的。 spring: cloud: gateway: routes: - id: test1 uri: http://www.baidu.com predicates: - Path=/baidu/** filters: - StripPrefix=1 通过请求参数匹配 Query Route Predicate 支持传入两个参数,一个是属性名一个为属性值,属性值可以是正则表达式。 spring: cloud: gateway: routes: - id: query_route uri: http://www.baidu.com predicates: - Query=type,baidu 如上图所示,输入 localhost:8088/?type=baidu 会被转发到 https://www.baidu.com/?type=baidu 如果写成 - Query=type,这样配置,只要请求中包含 type 属性的参数即可匹配路由。 通过请求 ip 地址进行匹配 spring: cloud: gateway: routes: - id: remoteaddr_route uri: http://www.baidu.com predicates: - RemoteAddr=192.168.1.1/24 组合使用 以上示例演示了单个 Predicate 的使用,Predicate 也可以放在一起组合使用。 spring: cloud: gateway: routes: - id: combination_route uri: http://ityouknow.com predicates: - RemoteAddr=192.168.1.1/24 - Query=type,baidu - Path=/baidu/** 各种 Predicates 同时存在于同一个路由时,请求必须同时满足所有的条件才被这个路由匹配。 一个请求满足多个路由的 Predicate 条件时,请求只会被首个成功匹配的路由转发 如何自己实现 Predicate 以上介绍了内置的 Predicate 的使用,但是在一些特殊的场景下,内置的 Predicate 可能满足不了我们的需求,这个时候我们就可以根据 Gateway 提供的接口实现自己的 Predicate。 需求背景 系统中有一些请求需要根据参数去转发,比如根据查询参数的某一个范围去转发,例如 /server?type=A,当 type 为 A、B、C 三个其中一个值时转发到 server1 服务,type 为 D、E、F 三个其中一个值时转发到 server2 服务。我们可以通过继承 org.springframework.cloud.gateway.handler.predicate.AbstractRoutePredicateFactory 实现 /** * 工作流相关的断言 * * @author zhangtao * @since 2020-01-06 7:26 下午 */ @Component public class TypeRoutePredicateFactory extends AbstractRoutePredicateFactory<WorkFlowRoutePredicateFactory.Config> { public WorkFlowRoutePredicateFactory() { super(WorkFlowRoutePredicateFactory.Config.class); } private static final String DATETIME_KEY = "type"; @Override public List<String> shortcutFieldOrder() { return Collections.singletonList(DATETIME_KEY); } // 配置参数的类型,此时指定为List @Override public ShortcutType shortcutType() { return ShortcutType.GATHER_LIST; } // 判断的逻辑,如果返回为true则匹配成功 @Override public Predicate<ServerWebExchange> apply(WorkFlowRoutePredicateFactory.Config config) { return new GatewayPredicate() { @Override public boolean test(ServerWebExchange exchange) { // 判断参数中是否有配置的type List<String> types = exchange.getRequest().getQueryParams().get("type"); if (types != null && types.size() == 1 && config.getType().contains(types.get(0))) { return true; } return false; } }; } @Validated public static class Config { private List<String> type = new ArrayList<>(); public List<String> getType() { return type; } public void setType(List<String> type) { this.type = type; } } } 配置文件: spring: cloud: gateway: routes: - id: server1-route uri: http://www.baidu.com predicates: # Type为,TypeRoutePredicateFactory类 RoutePredicateFactory前面的值 - Type=A,B,C - id: server2-route uri: https://cn.bing.com/ predicates: # Type为,TypeRoutePredicateFactory类 RoutePredicateFactory前面的值 - Type=D,E,F 以上配置为,当请求参数中 type 的值为 A、B、C 其中一个时则匹配成功,通过 server1-route 路由转发到 http://www.baidu.com,当请求参数中 type 的值为 D、E、F 其中一个时则匹配成功,通过 server2-route 路由转发到 https://cn.bing.com/ 总结 Spring Cloud Gateway 使用非常的灵活,可以根据不同的情况来进行路由分发,在实际项目中可以自由组合使用。同时 Spring Cloud Gateway 还有更多很酷的功能,比如 Filter、熔断和限流等。 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/live 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间:2020-07-01本文作者:张sir本文来自:“infoq”,了解相关信息可以关注“infoq”
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 苹果正在制造一款AR耳机、一款AR眼镜,大概在2021年、2022年或2023年正式公布......这样的计划或者报告铺天盖地,似乎一切都在向好的方向发展。 然而,在今年的全球开发者大会(WWDC)上,这些计划苹果并没有公布,也没有任何暗示。相反,很多无法回答的问题有待解决。 过去四年里,苹果公司首席执行官蒂姆·库克(Tim Cook)曾多次表示,增强现实(AR)将成为公司未来发展的重要组成部分。面对谷歌、Facebook、微软、高通等公司的竞争,苹果仍有能力制造可能引起巨大轰动的硬件,比如数百万部iphone、ipad、产品生态系统,以及AR图形工具包。 然而,由于每个人都被困在家里过虚拟生活,增强现实体验在今年的活动中被淡化了。 去年,苹果发布了集成的AR工具,允许多人体验和构建虚拟世界。今年,苹果在iOS 14和iPadOS 14中更新的ARKit 4工具虽然发挥了关键作用,但似乎少了一些动态的新元素。 随着更多细节的透露,你会发现:有深度感应的iPad、有空间感知能力的AirPods、苹果地图的定位标记等,将成为通往虚拟世界的入口。 iPad Pro的深度感应是关键 2020年春季发布的iPad Pro有一个独特的激光雷达传感器,可以扫描真实空间并创建3D地图。 这一扫描功能,未来很有可能搭载在iphone上,并最终出现在苹果的AR耳机中。 苹果新推出的面向开发者的ARKit 4工具包有一个Depth API,该API将更好地利用传感器,并承诺提供更精确的测量。开发人员已经开始使用激光雷达来扫描房屋和空间,并对扫描进行筛选,这种扫描不仅可以用于增强现实,还可以用于以CAD等格式保存地点模型。 苹果地图上标记的点,未来可以显示现实世界的景象 地图位置和增强现实,进一步融合 就像微软、Snapchat和谷歌一样,苹果也在其iOS 14 AR工具中添加了定位锚,但使用了一些精确工具来排列GPS和苹果地图数据。 这些特定的地理位置标记将使虚拟事物更容易固定在特定的地方。 微软去年发布的《我的世界》(Minecraft Earth)已经有了特定位置的锚。苹果似乎准备进一步推进这一想法,试图把人类体验与城市地图联系起来。 结合AR已经实现的多用户可能性,这将导致现实中更多的共享和压缩,比如特定位置的艺术体验。不过有一件事很有趣:苹果公司表示,由于它依赖更先进的苹果地图数据来协调和微调定位,新的地理定位锚目前只能在美国某些主要城市使用。 新程序,将快速扫描启动AR iOS 14的一项新功能名为App Clips,它承诺在NFC扫描或使用QR码时,会快速地显示App片段。 这可能意味着一个NFC水龙头或二维码扫描就可以启动一个基于“增大化现实”技术应用,而不需要下载一个完整的应用程序。 AirPods Pro可以做空间音频,这可能导致环境音频增强现实。 AirPods Pro上的空间音频看起来像苹果的AR音频 去年,我开始考虑把音频作为增强现实的关键:不用拿起电话甚至眼镜去体验虚拟世界,音频这种体验方式有一个好处——受到的干扰会更少。 毕竟,我们一直都戴着耳机,生活在音频泡泡里。苹果的AirPods经常被视为沉浸式未来的“先驱”。 iOS 14允许在苹果的step up AirPods Pro模型中使用空间音频,通过移动跟踪来定位音频位置,而这取决于你的头部如何移动。 目前,它的功能是在iPhone或iPad上听环绕立体声,苹果还没有将AirPods Pro的空间音频集成到ARKIt中,但这也可以应用到音频AR体验中。再加上眼镜,就完美了。 苹果AR,可以播放虚拟视频屏幕了 ARKit 4中有一个很常见的功能叫做“视频纹理”,它可以将视频投影到AR中,比如Magic Leap,它可以用于浮动电视屏幕,或者将移动的视频角色映射到3D模型上。 现在,当iPhone或iPad只是一个迷你电视屏幕时,用你的iPhone或iPad在你的客厅里创建一个浮动的虚拟电视屏幕似乎有些愚蠢。但是,戴上眼镜,这个想法看起来一点也不傻。 全息投影的想法也很吸引人。目前,AR和VR并不能很好地在虚拟世界中显示人们的真实面孔;通常感觉更像是生活在一个卡通或木偶世界里。 即使在像Spatial这样的虚拟缩放会议应用程序中,头像看起来也像是真实熟人的粗略拉伸。在未来的AR FaceTime通话中,视频映射化身将可能实现你与朋友以全息影像的方式见面。 结语 如果你曾期待苹果在AR(或VR)领域有什么大的突破,那么现在已经不可能了。 没有苹果耳机、也没有苹果眼镜,苹果也没有将AR耳机插入苹果设备的能力。让人稍稍欣慰的是,苹果的AR工具正在变得非常先进。 参考链接:https://www.cnet.com/news/apples-future-ar-pieces-hid-in-the-corners-during-a-virtual-wwdc/ 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/live 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间:2020-06-30本文作者:周舟本文来自:“ 雷锋网”,了解相关信息可以关注“雷锋网”
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 现在的情况是这样的:你在浏览器中输入twitter.com,然后就看到某人发了一条关于如何使用React Hooks的新推文。但是,由于某些原因,你的公司或团队尚未切换到Hooks,又或者,也许你们已经在用了,但不是以新的“流行”的那种方式用。也许你们用的是Vue.js或Angular,但是现在这些关于React Hooks的信息随处可见,甚至你会觉得在晚饭的时候,关于React Hooks的消息几乎都要出现在你的微波炉上了。 鉴于现在这种情况,你开始质疑,自己的代码库中的内容是否正确?是不是应该使用刚刚看的技术文章内容来重构这块逻辑?随着心中的疑问告一段落,你开始想象实际代码的样子。 而现在,你突然有了使用它的冲动。你联系团队负责人,或者向整个团队发消息,把这个超酷的新方法告诉他们,并建议开始使用它。 重写代码 (图片大意:这次你选的库和构建工具肯定是正确的了,真实世界:每六个月重写一遍你的前端代码)前段时间,@ ThePracticalDev 的Twitter帐号上发表了一本不存在的书的封面。早在2016年,开玩笑揶揄不断变化的JavaScript世界就已经是一种时尚了,但方式和当今有所不同。 嘘,我发明了时光机(不要告诉别人)!让我们快速穿越回到2016年。 咻!好了咱们到了。现在JavaScript的环境是这样的: 如果你已经在使用JavaScript框架了,或者想要使用,则可能会选择Angular.js。但是,Angular 2马上就要来临,它的新特性会使得你需要重写几乎所有内容。另外,一个名为React.js的新秀即将成熟,马上就要粉墨登场。当然,Vanilla JS和不使用框架的人也是存在的。在2016年,不使用框架仍然是一种流行的观点,但是正在逐渐消亡中。 在了解了这一切之后,你会怎么做?你会选择哪条路,理由又是什么?作为一个从未来穿越回来的人,现在答案似乎很明显了,那就是React。但是,如果你决定使用Angular.js,在接下来的几年里你将很容易受到诱惑而去使用新的Angular版本,并重写代码。如果你选择使用React,那么你将是一个幸运的赢家,因为当今每个人都上了React这条船。而现在,你很想丢弃类组件,转而使用那些美妙诱人的Hooks函数组件,对吗?好吧,至少这不像Angular.js到Angular 2的跨度那么大,起码不需要学习一个全新的API,对吧? 选择太多,时间太少。该怎么办? 我们现在选择什么,或者我们过去选择了什么都没关系。我们仍然会被诱惑,或者不得不在日后重写自己的代码。原因可能是多种多样的: 你的公司以前使用的是(任意框架名称),并且无法雇用新员工 你觉得旧的解决方案不再适合自己,并且你想要新元素 你顺应了行业趋势,并希望使用最新和最好的技术。 除非我们打破这个循环。 打破循环 不断改进,并发布更新更好版本的基因已深深刻入我们这个行业。对于更高效,更简单,更美观,更健壮解决方案的需求鞭策我们前进。破坏持续学习和进步的想法是与当今所有事物背道而驰的。我现在还不会去走这条路,但是如果你想在以后了解更多关于这方面的信息,请考虑订阅我的newsletter。 不断学习新事物的想法是好的,我对此也表示同意,但问题是应该多久学一次呢?纵观JavaScript的世界,新的想法、博客文章、库、框架以及诸如此类的东西你方唱罢我登场。当一样东西流行起来,人们就迅速尝试去采用。我并不是说你不应该拥抱新事物,或者不应该考虑采用不同的方法来解决问题,我完全不是这个意思。我想表达的是,这种事情能不能做得不要那么勤。 让我们更加务实一点吧。我以前使用过axios,效果很好。你可以对其进行测试,支持广泛,具有很高的得分(GitHub星标),等等。然后,我看到一篇博客文章,告诉大家要替换axios,实施自己的fetching logic。 在看了文章“用简单的自定义fetch wrapper替换axios”的标题后,它吸引着你顺着作者的思路从头读到尾。它使你质疑自己之前的选择。 我不会详细给你介绍是否应该采用帖子的做法,帖子本身已经说得很清楚了。然而我可以帮助你进行基本决策。 你现在对axios满意吗?如果答案是肯定的,则最好把替换它的想法放到一边。axios对你或你的团队来说很困难吗?如果答案是肯定的,请尝试听从该帖子的建议,并看看效果如何。 简而言之:不要轻信天花乱坠的宣传。尝试去“感受”哪个适合你,然后就选择哪个。尽量不要屈服于浮华的新推文,博客文章,Hacker News热门文章,应做或不应该做的热门话题标签。请继续读下去,以了解如何避免这种炒作驱动的开发。 HDD-炒作驱动开发(Hype Driven Development) 炒作在我们行业中很普遍。还记得NoSQL吗?还有当每个人都对微服务爱的死去活来的那时候?或者AI /机器学习的大爆发?数都数不清。人们总是对新的突破性技术和想法感到兴奋。Gartner的炒作周期曲线简直太对了: 它展示的是新兴技术的典型生命周期。你是否能想出自己正在使用的某样东西可能正好落入图表的某个阶段?Ayman制作了更详细的炒作周期图: 在想追随最近某个JS趋势的时候想一下这个曲线,它处在哪个位置上? 如何对待技术热潮? 这种炒作和兴奋感有时在生活中还挺有用的。如果没有它,生活将变得乏味而无聊。时不时地追随一下热点和潮流,可能会给人耳目一新的感觉,但是你始终应该先做好功课。 在尝试采用全新的热门库或框架时,请记住这一点,向你自己和你的团队提出以下问题: 在做决定之前进行研究和测试 阅读博客文章,推文和公告也许有帮助,但要获得最佳体验,了解一样东西适不适合自己,是需要去亲身经历的。试着用你打算使用的技术搭建一个原型出来。看看它与你正在做的其他事情配合得怎么样。 如果你打算在团队级施展某样东西,那么可以试试团队黑客马拉松。黑客马拉松是与团队一起测试新技术的好方法,而且你可以尽情挥洒创造力来解决问题。然后,你可以与团队进行某种回顾,讨论技术的优缺点。 它能解决您的问题吗?代价是多少? 你目前的方式是否存在某个特定的问题?如果是的话,请测试一下新技术是否能够解决这个问题。学习这个技术需要多少时间?学习并重写以前的解决方案是否值得?它会在多大程度上减慢你团队的开发进度? 征求他人意见 如果你在小型公司工作,或你的团队缺乏有经验的成员,那这一项可能会比较难。试着去寻求架构师或高级工程师的意见吧。仅仅因为某些库能够为AirBnB及其网站提供良好的服务,并不意味着这对你而言也是最佳选择,你可能忽略了它的某些方面。与经验丰富的人交谈有时是一种荣幸,如果可以,请不要浪费机会! 如果你是高级开发人员,请试着与初级开发或经验不足的人聊聊。许多公司正在运行所谓的“反向指导”计划,让初级人员指导公司的高级成员。高级人员的经验用来交换初级人员的新奇角度。你会惊讶地发现可以学习和分享的东西有很多。 总之,请不要因为自己刚刚看到了什么热点内容就草率地做出决定。 原文:https://pragmaticpineapple.com/do-not-follow-javascript-trends/ 作者简介:Nikola Đuza,工作语言为JavaScript和Ruby,现居诺维萨德。 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/live 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间:2020-06-29本文作者:Nikola Đuza本文来自:“ CSDN”,了解相关信息可以关注“ CSDN”
云栖号资讯:【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 物流系统的难题 菜鸟的物流系统脱胎于天猫、共享交易,系统之间存在着 " 打断腿连着皮 " 的紧密的联系,多年来双方配合默契,承担着整个泛电商业务最核心的链路。 随着集团业务的蓬勃发展,线上购物更加深入人心,在每年双十一订单峰值纪录不断被打破的背后,技术投入和成本也在不断增加,特别是近几年,支付的能力提升已经渐渐可以和下单持平,这对物流系统的压力也越来越大。交易和物流两者间密不可分的技术脐带逐步变成了缠绕在菜鸟脚上的链条。 双十一的巨大成本压力 仅分析 2015 年双十一峰值背后的业务数据,其中 0 点起创建的订单,在前一个小时完成发货的订单仅有几十万, 相比支付订单量可以说九牛一毛,可以看出,支撑大流量高并发的订单创建,并非物流领域自身业务的刚需驱动,而更多的是为了保障交易 - 支付 - 物流链路的稳定。 再从业务场景上来看,物流在双十一是以单据驱动的核心业务,即发货。发货对应的是实物的实操业务,需要大量的人力物力投入,这种物理空间上的线下协同能力,具有流量相对平稳,无明显峰值的特点,整个业务流程复杂、业务执行周期长、参与角色较多。从用户的核心诉求来说,用户只关心交易订单是否成功创建,而物流订单是否能马上创建出来,并不是刚需。 因此,如果交易订单的创建峰值每年持续上涨,物流系统就需要对等部署同样的机器来保证同步链路的顺利执行,从物流业务的特点来说,这不是必须的,对一个非刚需的场景,每年投入大量的成本来保证同步链路,是非常不明智的,物流系统的架构升级已经刻不容缓。 RocketMQ——菜鸟架构师的选择 这也是菜鸟的系统架构师王维在 2016 年双十一前面对的最大挑战,那一年双十一的订单创建峰值要从 15 年的 18 w 涨到 30 w。他要做一次意义重大的升级,让交易和菜鸟的业务能更清晰的划清业务模型和链路,让天猫快速激增的系统流量不再让菜鸟系统追赶,让菜鸟能专注去完成物流领域内的事情,让天猫交易能更专注的保障交易链路的稳定。 在双十一订单峰值的要求下, DB 和 REDIS 显然不能满足异步解耦的要求,因此王维将目光锁定在了 RocketMQ 上,一个在阿里集团内部广泛使用的分布式消息中间件。 RocketMQ 在阿里巴巴已经经受了双十一多年的的洗礼,服务性能已经是世界领先水平,可以支持用户亿级的堆积,同时客户端也提供完善的 SDK 让用户能做到精确的控速消费,在架构解耦和削峰填谷上,有明显的优势。 使用 RocketMQ 做异步解耦,物流订单中心在满足自身领域业务的前提下,只要保持一个较高水位平稳消化支付的交易订单流量,无需承受交易支付的高峰,既可以减少大量的人力物力成本投入,可以规避同步依赖时的稳定性风险。两个系统保持良好的沟通,更加专注做好自己的事。简单说,如果交易创建的峰值是 50w/s, 持续 20 分钟,如果物流系统通过 RocketMQ 控制消费速度,比如保证 8w/s 的消费,那么也可以在 2 小时内消费完所有的数据,对用户来说,整个过程也是无损无感的。 与消息中间件团队深度合作,充分利用 MQ 削峰填谷的作用后,在 2016 年双十一前,通过 2 个的月的开发、测试、验证、灰度等工作后,王维成功推动了菜鸟系统架构从电商高并发向更加贴合物流作业的特点转型。16 年后,在电商持续攀高的下单峰值背景下 (4 倍增长),菜鸟物流系统峰值 QPS 保持不变,节省了大量技术成本,并且为未来多年的成本降低奠定了基础。 菜鸟的系统架构师如何应对交易系统激增的系统流量 【云栖号在线课堂】每天都有产品技术专家分享!课程地址:https://yqh.aliyun.com/live 立即加入社群,与专家面对面,及时了解课程最新动态!【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK 原文发布时间:2020-06-25本文作者:不铭本文来自:“infoq”,了解相关信息可以关注“infoq”
2019年11月