mesh

企业在向微服务架构转型的进程中都不免面临这样的问题：当部署在云原生平台上的微服务应用程序到达一定规模后，众多服务间的调用与通讯变得十分复杂，Service Mesh（服务网格）的出现改变了这一现状。 Service Mesh 通过将一组轻量级网络代理与 服务 部署在一起， 并 对 服务本身 透明，使得每个服务间的请求传递更加流畅、可靠和迅速。 SolarMesh 致力于提供成熟、易用性更高的服务网格方案及产品，帮助企业更好地进行服务治理，并且已经在落地实践中初见成效。 SolarMesh —— 基于服务网格的可视化微服务治理平台 SolarMesh 服务网格是一个高效可视化微服务治理平台，基于开源项目 Istio ，提供应用生命周期管理、全面流量管理和非侵入式的服务治理解决方案。 目前 SolarMesh 已正式上线，欢迎进入 SolarMesh 官方网页 免费下载体验。 全面的服务网格解决方案 成熟的服务网格落地方案 SolarMesh 采用业界成熟的服务网格技术选型并进行调优，基于 "服务+代理" 模式，以非侵入式的方式对微服务进行完备的流量代理，无需修改代码/配置，即可获得完整的微服务流量管理能力。 全方位流量视图 在微服务架构中，服务的行为通常是未知的，为了探索微服务的未知状态，服务必须具备可观测性。 SolarMesh 通过捕获通信起止服务、网络协议、请求内容等数据

最近，O’Reilly 公布了一份关于企业微服务市场现状的数据调研。报告显示，在访问了全球 1,502 名软件工程师、系统和技术架构师、工程师以及决策者后，有 77％ 的组织反馈采用了微服务，其中 92％ 的组织成功使用了微服务。 如果以这份报告为依据，微服务在企业的普及率已接近八成。看起来，企业对微服务的兴趣可能已经接近顶峰。 云原生的基础设施从设计上保证了它是微服务部署的最佳平台，但是也对现有的微服务框架带来了新的挑战 ，在云原生大行其道的今天： 我们对微服务还应该继续投入精力关注吗？ 云原生和微服务之间的关系是什么？ 随着 Serviece Mesh 等技术的不断成熟，微服务的体系和思想会产生怎样的演化？ Spring Cloud、Dubbo 还会继续作为微服务开发框架的继续流行下去吗？ 容器、Kubernetes、ServiceMesh、Serverless 这些云原生时代的主角，会如何助力下一代微服务架构为业务发展赋能？ 这些问题值得每一位技术从业人员去思考，并发现由此带来的企业数字化转型升级新挑战、新机遇。也许有同学会说：“上个阶段微服务架构的问题都还没解决，又来了个‘云原生时代的微服务’，我这从哪儿开始学起啊？” 来，从这儿开始！ 2020 云原生微服务大会 为推动云原生下的微服务技术发展和实践交流，由阿里云主办的首届“云原生微服务大会”将于 2020 年 8 月

1）MMORPG手游合理的性能参数 ​2）使用ScriptableBuildPipeline打包的疑问 3）如何获取到Animation修改材质球颜色后的颜色值 4）嵌套预设AssetBundle打包的疑问 5）LWRP渲染下，Profiler中函数开销高 这是第219篇UWA技术知识分享的推送。今天我们继续为大家精选了若干和开发、优化相关的问题，建议阅读时间10分钟，认真读完必有收获。 UWA 问答社区： answer.uwa4d.com UWA QQ群2：793972859（原群已满员） Performance Q：想请教一下大家，一款MMORPG游戏上线时的性能参数是如何制定的？有没有可参考的性能参数可以指导一下？ A1：制定指标要根据多方维度来综合考虑，包括产品定位、团队水平、成本预算和时间预算等等，很难一概而论，以下是我们针对新项目立项要指定美术指标时一贯的做法，可以参考： 拿对标美术表现的竞品来看他们各项性能指标如何，用RenderDoc或者NSight能够得到比较准确的数据，也可以抽出他们资源来做下一步操作。 制作效果Demo，尝试技术上还原竞品的效果，这时尽量做到表现上和性能上都能还原。 有了效果Demo后，基本指标已经有了，不过还是得自己团队从美术到技术再到策划完整地把流程跑通，而且可能还要对表现的要求进行提高以提升产品竞争力

点击上方“ 3D视觉工坊 ”，选择“星标” 干货第一时间送达 1. 三维曲面解码 基于体积表示的方法在计算上非常浪费，因为信息只在三维形状的表面或其附近丰富。直接处理曲面时的主要挑战是，网格或点云等常见表示没有规则的结构，因此，它们不容易适应深度学习体系结构，特别是使用CNN的体系结构。本节介绍用于解决此问题的技术，将最新技术分为三大类：基于参数化、基于模板变形和基于点的方法。 1.1 基于参数化的三维重建 与直接使用三角形网格不同，我们可以将三维形状X的表面表示为映射ζ：D→R 3 ，其中D是正则参数化域。然后，3D重建过程的目标是从输入I中恢复形状函数ζ。当D是3D域时，这类方法属于第4节中描述的体积技术。 这里，重点讨论D是正则2D域的情况，它可以是二维平面的子集，例如D=[0，1] 2 ，或者是单位球面，即D=S 2 。在第一种情况下，可以使用标准的2D卷积操作来实现编码器-解码器架构。在后一种情况下，必须使用球面卷积，因为域是球面的。 球面参数化和几何图像是最常用的参数化。然而，它们只适用于0属和盘状表面。任意拓扑的曲面需要切割成圆盘状的曲面片，然后展开成规则的二维区域。找到给定曲面的最佳切割，更重要的是，在同一类别的形状之间找到一致的切割是一项挑战。事实上，单纯地为形状类别创建独立的几何图像并将其输入深层神经网络将无法生成连贯的三维形状曲面。

目录 文章目录 目录 微服务架构与云原生 Service Mesh 流量治理 微服务架构与云原生 从微服务架构的思想，我们可以感受到微服务架构、DevOps 和容器技术自然地走到了一起，构成了云原生应用架构的雏形。 在云原生时代，微服务的特点： 平台化 ：利用云作为一个平台，为微服务架构进行更多的赋能。 标准化 ：我们希望微服务本身的部署、运维，微服务之间与其它服务之间的通讯都能做到标准化，让服务与服务之间的互联互通变得更容易，服务能够跨到不同的平台上，做到一次编写、一次定义、多处运行。 微服务轻量化 ：让研发人员关心核心业务代码、业务逻辑的研发，而不是复杂的微服务治理相关的逻辑研发。 微服务的产品化 ：希望能构建微服务相关的产品，以产品化的方式支持大家使用微服务架构，让它变得更好用、更易用。 微服务架构首先要面对分布式架构的内生复杂性。微服务框架需要能够解决服务通信和服务治理的复杂性，比如服务发现、熔断、限流、全链路追踪等挑战。 微服务框架，如 HSF/Dubbo 或 Spring Cloud 以代码库的方式来封装这些能力。这些代码库被构建在应用程序本身中，随着应用一起发布和维护。 服务通信和治理本质是横向的系统级关注，是与业务逻辑正交的。但在微服务架构中，其实现方式和生命周期与业务逻辑耦合在一起的。 微服务框架的升级会导致整个服务应用的重新构建和部署

【以下为分享实录，有删节】 测试环境管理之困与阿里巴巴的解决之道 在云原生时代下，软件的迭代速度越来越快，对测试的要求也越来越高，很多开发者开始使用Kubernetes来管理测试环境。在这个过程中，开发者会遇到很多困难，其中最主要的两个问题是：一、本地环境与Kubernetes集群网络不通问题；二、共用测试环境时，相互干扰的问题。 在阿里巴巴内部，我们主要通过扁平的内网IP和项目环境两个机制来解决以上痛点。扁平的内网IP主要是基于CNI(Conteinre Network Interface) 机制改造Kubernetes的IP逻辑实现的，可以使集群中的每个Pod分配到的IP与本地机器分配到的IP处于一个大的网络环境下，这样就可以解决本地环境和集群之间互通的问题。项目环境是基于RPC、消息中间件的虚拟环境，从表面上看，每个项目环境都是一套独立完整的测试环境，由一系列服务组成集群，而实际上，除了个别当前使用者想要测试的服务，其余服务都是通过路由系统和消息中间件虚拟出来的，指向公共基础环境的相应服务。这样操作的好处是，第一不会占用大量的开发资源；第二，不会影响公共基础环境的稳定性。 阿里巴巴的这种测试环境带来的测试体验非常爽，本地与集群双向互通，每个子项目都可以独占一个“项目环境”，彼此不会干扰。但是这种测试环境管理方式实施起来比较复杂，只适合大型的集团公司，我们希望将这种测试体验以

1.总结 ①不要买百兆网口路由器，千兆网口起步 ②必须买双频路由器（2.4G—5G）或者三频 ③无线速率1200兆起步 ④必须支持802.11ac或ax标准 ⑤必须支持2*2mimo以上技术的路由器（新MU—MIMO技术更好） ⑥不要盲目选购WIFI6，价格较贵，而且配套设备没跟上 ⑦网线至少需要千兆（超五，六类，超六）不差钱上（七类） ⑧面积大于120平还需要无缝漫游 要么多花钱上mesh 要么路由+多AP模式 ⑨5G速度快，穿墙弱，跟价格无关 ⑩信号覆盖面积，200和1000元的路由器差别不太多，大体上是国标发射功率低导致 （11）布置多个路由器，要尽量使用有线连接，而不是无限桥接 （12）网速超过100兆，降低网络延迟提升长时间运行稳定性，远比提升网速更重要 （13）不要太相信厂商宣传双频合一，绝大多数都做的不好 （14）连接设备超过50台，选择企业级路由器 （15）路由器尽量摆放你想覆盖区域中间位置，尽量避免其他物品遮盖阻挡 （16）日常使用一定选择固件好的路由器 喜欢刷机无视原厂固件，主看硬件 2.推荐链接 https://zhuanlan.zhihu.com/p/43278913 https://zhuanlan.zhihu.com/p/95210268 来源： oschina 链接： https://my.oschina.net/u/4350320/blog

作者 | 郭浩（项升） 阿里巴巴经济体 RPC 框架负责人 **导读：**本文整理自作者于 2020 年云原生微服务大会上的分享《Dubbo3.0 - 开启下一代云原生微服务》，主要介绍了关于思考 rpc 框架层面，功能演进的方向是什么？以及怎么更好地支持云上的多语言开发的新思考。 关注阿里巴巴云原生公众号，后台回复 【818】 即可获取直播回看地址和大会 PPT 合集。 看到这个题目，大家可能会有几个问题，比如，什么是云原生微服务？Dubbo3.0 是什么？和目前的 Dubbo2.0 有什么区别？用了 Dubbo3.0 会带来哪些业务视角的好处？后面的分享会对这些问题逐一解答。 这次分享分为以下几个环节： Dubbo 的演进历史 Dubbo 的开源现状 定义 Dubbo3.0 分享 Dubbo 3.0 目前取得的一些成果 考虑到有些同学对 Dubbo 可能不太熟悉，在介绍背景之前，我先简单介绍一下 Dubbo 是什么。简单地说，Dubbo 是基于 Java 的 RPC 框架。一个 RPC 框架至少由数据格式、传输协议和连接管理组成，这三点也是构成核心。Dubbo 能够被广泛应用主要有两个原因： 一方面是较好的插件机制支撑了多种扩展，这些扩展在不同业务场景和基础架构中能分别发挥最大优势； 另一方面不同于普通的 RPC 框架，Dubbo 的服务治理功能让其在易用性方面脱颖而出

微服务、云原生、Kubernetes. Service Mesh 是分布式领域的热点技术，它们并不是凭空出现的，一定继承了某些“前辈”的优点。我们不仅要了解这些技术，还要深入理解其发展脉络、原理等，才能游刃有余地将其用于现有的项目开发或老系统改造中。 不论你是有十几年研发经验及架构经验的IT老手，还是刚入门系统架构的IT新手，本书都能对你理解分布式架构和微服务架构大有助益。 卷轴目录 第1章 深入理解网络 从国际互联网开始 NIO,一本难念的经 AIO,大道至简的设计与苦涩的现实 网络传输中的对象序列化问题 HTTP的前世今生 分布式系统的基石: TCP/IP 第2章 分布式系统的经典理论 从分布式系统的设计理念说起 分布式系统的一致性原理 分布式系统的基石之ZooKeeper 经典的CAP理论 BASE准则，一个影响深远的指导思想 重新认识分布式事务 第3章 聊聊RPC 从IPG通信说起 古老又有生命力的RPC 从RPC到服务治理框架 基于ZeroC Ice的微服务架构指南 第4章 深入浅析内存 你所不知道的内存知识 内存计算技术的前世今生 内存缓存技术分析 内存计算产品分析 第5章 深入解析分布式文件存储 数据存储进化史 经典的网络文件系统NFS 高性能计算领域的分布式文件系统 企业级分布式文件系统GlusterFS 创新的Linux分布式存储系统一Ceph