mesh

之前见别人的文章总是说，在Hierachy下，相同图集的图片要连续排列，这样Unity会对相同图集的图片进行合批，从而减少draw call。今天做了简单的试验发现情况并不是这么简单的。 第一种情况： 如上图所示，在Hierachy下图片层级从低到高分别是（p，+，+），得到draw call为2。 第二张情况： 如上图所示，在Hierachy下图片层级从低到高分别是（+，p，p），得到draw call为3。 第三种情况： 如上图所示，在Hierachy下图片层级从低到高还是（+，p，p），只不过我把p的图片由瓶子换成了一个鸡蛋，其实就是换了一个图集，得到draw call为2。 目前总结来的结论应该是这样的，如下图所示，A，B两张图应该是先渲染的，因为它们分别处于更远的depth，C是后渲染的，因为它处于更近的depth。但是A和B谁先渲染决定与它们使用的图集，这个优先级在我刚刚举的三个例子中应该是 瓶子图集 > 加号图集 > 鸡蛋图集。所以在下图中 A和B应该是先渲染A，所以渲染顺序是 A(瓶子) - B(加号) - C(瓶子)，无法合批，一共三次draw call。但是如果把瓶子换成鸡蛋，那么A和B应该是先渲染B，所以渲染顺序是 B(加号) - A(鸡蛋) - C(鸡蛋)，后两次鸡蛋可以合批，一共两次draw call。 但是在上图的情况下，我们稍稍改变B的pos.z

内容概要 Service Mesh 是干啥的？解决了什么问题？ Service Mesh 的特性 Service Mesh 的主流实现有哪些？ 1. Service Mesh 是什么？ 简单来讲，Service Mesh 简化 了微服务架构中服务间 调用复杂度 。 这就涉及到了2个问题： 服务调用怎么复杂了？ Service Mesh 怎么解决的？ （1）服务调用复杂度问题 对于每个微服务，我们可以简单的视为包含2个部分： 业务逻辑 网络功能 其中网络部分是非常复杂的，需要解决很多问题，例如： 使用什么网络传输协议（HTTP1.x/2.x, gRPC ……） 服务发现 熔断机制 处理超时 重试 服务调用时的负载均衡 …… 每个微服务都需要处理这些网络问题，如果所有微服务都使用同一套语言还好，可以使用一个框架统一解决，但如果使用了多种语言，那么每种语言又需要统一处理一遍。 所以，可以说： 微服务架构中， 最复杂 的不是构建服务本身，而是处理 服务间调用问题 。 （2）Service Mesh 怎么解决的？ 核心部分说明： 业务逻辑 微服务实现自己的业务功能。 内部网络功能 虽然很多网络功能都可以统一由 Service Mesh 解决，但有些基础的功能还需要微服务自己来解决。 例如，和 Service Mesh 如何沟通呢？使用 HTTP1.x, gRPC, TCP?

1 背景 起初，在网盘快速发展期，为了快速上线，采用了服务单体化 + 主干开发模式进行研发，随着用户规模爆发式的增长以及产品形态的丰富，单体化的不足就体现出来了，于是架构上采用了微服务架构，开始对业务逻辑进行拆分部署。 服务拆分之后，也引入了新的问题，具体如下： **请求路由：**服务部署从物理机向虚拟化方式迁移中，有大量的切流量操作，需要相关的上游都进行升级上线修改，效率低下 **故障管理：**单实例异常、服务级别异常、机房故障异常、网络异常等，严重缺失或者不完善，同时配套的故障定位也没有，服务稳定性不足 **流量转发：**不同的服务采用了不同的框架，甚至裸框架，策略不完善，导致负载不均衡 **研发效率：**相同的功能点，需要在不同的语言框架上实现一次，浪费人力，同时升级周期比较长，收敛效率低 2 解决方案 - UFC 2.1 UFC 发展史 为了解决这个问题，从2015年底开始思考解决方案，确定了解决问题的核心在于管控请求流量，在2016年开始自研网络流量转发中间件 - UFC(Unified Flow Control)，业务通过同机部署的agent进行服务通信，相关的发展史如下： 2.2 UFC 和 Service Mesh的关系 后来在调研业界相关技术的时候，发现了istio(业界Service Mesh的典型代表)，从而发现了Service Mesh的存在

作者 | 阿里巴巴云原生 新年伊始，新兴冠状病毒肺炎席卷而来，社会各界同心协力，抗击疫情。 你也许听说了阿里巴巴迅速设立 10 亿元医疗物资供给专项基金，也听说了马云公益基金捐赠 1 亿元，支持加快新型冠状病毒疫苗研发；菜鸟物流绿色通道，支持全球救援物资免费运输。而阿里云作为数字经济的基础设施更是强力支撑着各行各业的客户。 作为中国第一款支持云端实时协作的企业办公服务软件，石墨文档在疫情防控期间，借助阿里云函数计算极值弹性，不仅全面助力企业组织高效协同运转，守护员工健康；更成为人们爱心传递的利器。 石墨文档在疫情期间做了什么？ 1. 助力远程、实时协同办工 在疫情期间，石墨文档向奋战在疫情防控一线的政府部门、医疗组织、公益组织、社会团队、个人志愿者等免费提供高级版产品及服务。并在近日紧急发布了「远程办公版」，为企业组织带来了一系列远程办公模板。可实现多人多地在线实时协同、远程办公模板随时使用并有专属在线客服即时沟通等服务。 2. 助力爱心传递 社会各界爱心人士纷纷用石墨文档协作，共享武汉地区物资捐赠方式，高峰时刻实现了百人同时协作的场景。 杭州市发布严管令之后，很多宠物猫主人无法返杭，爱猫人士及杭州动物保护协会也开始使用石墨文档实时更新汇总杭州留守猫咪信息 400 多条，让同小区的“铲屎官“帮忙救助，截止到目前已解决 300 多家猫咪的救助问题。 面临挑战 1. 多用户实时协作

今天，「架构师成长系列直播」正式上线啦！ 疫情爆发，为了避免大家在线下聚集，我们决定延期举办众多 线下 Meetup 。我们迅速召集了包括 Apache Dubbo PMC、Apache RocketMQ 中国社区发起人& PMC、Spring Cloud Alibaba PMC 等 30+ 位阿里技术专家，以 “架构师成长” 为关注点，反复打磨内容，最终精选 4 个系列 33 课时，组成「架构师成长系列直播」。 直播内容涵盖 DevOps、微服务、容器、K8s、Serverless、消息 等热门技术，期待这套关注开发者日常工作痛点问题、提供实用技术技巧的课程，能够为你快速进阶架构师提供一些启发和参考。 从今天开始，每周一至周四 19：00 准时直播，让我们一起坚持打卡早日成为优秀架构师！ 今日直播预告 “ 阿里巴巴云原生 关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。” 来源： oschina 链接： https://my.oschina.net/u/3874284/blog/3167526

春节前的空档，正是静下来，回顾过往、畅想未来的最佳时期。 去年的这个时候，我们分享过一篇 《一位 70 后程序员的 26 个职场感悟》 。今年，我们同样分享一篇关于职场感悟的长文。本文是阿里巴巴资深技术专家崮德在内网的一篇分享，回顾了自己在大学时代、创业时期、硬件公司、互联网公司的一些经历和思考。 欢迎您在文末留言，聊聊自己或身边人的职场经历，我们将随机挑选 2 位寄出“ 阿里云定制台历 ”各一本。 我认为，热爱是一直努力的理由。 四个体感 体感一 ：学生时代正确的定位，会让进入职场的自己事半功倍 1998 - 2005 年，我在浙江大学就读电子工程，因为自己对电子工程的热爱和成绩优异，我本科保送研究生，研究方向是电路与系统，简单点就是硬件+嵌入式软件开发，因此自己天生就跨了学科，既有硬件电路设计，又有嵌入式软件开发。2005 年硕士毕业后，来到上海，加入了华为公司，从事基站硬件开发，也就是电子工程师一枚，负责单板设计，以及基站日常 bug 维护。从自己的经历发现，一个工科生掌握一两门不同学科的技能是可以让自己胜任更多有挑战的工作，也可以更容易脱颖而出。在华为，我就一边负责硬件单板设计，一边还参与其他部门的微码（类似汇编级别编程语言）开发，既做了硬件，也懂软件，在职业生涯的早期就给自己定位为综合性人才，为后续自己的技术发展奠定了很好的基础。 体感二：清楚了解自己的目标，并为之努力。

在刚刚过去的 2019 年里，阿里巴巴云原生公众号共发布了 270 篇文章，累计阅读 40 多万，文章内容涵盖阿里云原生实践、云原生生态新闻到 K8s 入门等。 这个春节假期，我们整理了三个最受欢迎的文章榜单， 包含系列文章、爆款文章和事件文章三类。 <a name="2MH8H"></a> 最受欢迎系列文章 Top 2 <a name="0ApGL"></a> 《Go 开发关键技术指南系列》 本系列文章从问题本身出发，不局限于 Go 语言，探讨服务器中常常遇到的问题，最后回到 Go 如何解决这些问题，为大家提供 Go 开发的关键技术指南。 本系列共有 4 篇： 为什么你要选择 Go？ (内含超全知识大图） Go 面向失败编程 带着服务器编程金刚经走进 2020 年 敢问路在何方？ <a name="x97ws"></a> 《从零开始入门 K8s》 由阿里云与 CNCF 共同开发的《CNCF x Alibaba 云原生技术公开课》（视频课程）第一期已更新完毕。为了让大家有更好的学习体验，我们把视频课程转为图文，并请讲师重新编辑成文章，在阿里巴巴云原生公众号以“从零入门 K8s” 为系列进行每周连载。本系列已发布图文版课程文章 21 篇，期待给正在学习 Kubernetes 的同学提供一些参考。 关注“阿里巴巴云原生”公众号，回复关键词“入门”，即可下载《CNCF x Alibaba

关注“阿里巴巴云原生”公众号，回复关键词**“入门”**，即可下载《CNCF x Alibaba 云原生技术公开课》PPT。 由阿里云与 CNCF 共同开发的《CNCF x Alibaba 云原生技术公开课》（视频课程）第一期已**更新完毕。**为了让大家有更好的学习体验，我们把视频课程转为图文，并请讲师重新编辑成文章，在公众号以“从零入门 K8s” 为系列进行每周连载。 本文整理了已发布图文版课程文章 21 篇，期待给正在学习 Kubernetes 的同学提供一些参考。 视频版课程 <br />点击访问：<br /> https://edu.aliyun.com/roadmap/cloudnative 图文版课程 <br />敬请关注阿里巴巴云原生公众号“从零入门 K8s”系列文章！ <a name="B1I7r"></a> 图文版课程 课时 1 ：第一堂“云原生”课 <br /> 课时 2 ：容器基本概念 <br /> 课时 3：Kubernetes 核心概念 <br /> 课时 4：理解 Pod 与容器设计模式 <br /> 课时 5：K8s 的应用编排与管理：核心原理 <br /> 课时 6： 应用配置管理: Deplyment <br /> 课时 7：应用编排与管理：Job & DaemonSet <br /> 课时 8： 应用配置管理 <br /> 课时 9

背景 有 外文 指出，2020 年 Service Mesh 技术将有以下三大发展： 快速增长的服务网格需求； Istio 很难被打败，很可能成为服务网格技术的事实标准； 出现更多的服务网格用例，WebAssembly 将带来新的可能。 针对 Service Mesh 技术，ServiceMesher 社区治理委员会成员在 2020 新年伊始发表了他们各自的看法，并邀请云原生与服务网格领域业界大牛抒发各自的见解，汇总成文，希望能给读者们带来一些思考和启发。 正文 宋净超（蚂蚁金服） 用一句话概括 Service Mesh 近几年的发展——道阻且长，行则将至。这几年来我一直在探寻云原生之道，从容器、Kubernetes 再到 Service Mesh，从底层的基础设施到越来越趋向于业务层面，Service Mesh 肯定不是云原生的终极形式，其复杂性依然很高，且业界标准也尚未形成，它的发展也远没有同期的 Kubernetes 那么顺利，但是很多人都已意识到了服务网格价值，现在它正在远离最初市场宣传时的喧嚣，走向真正的落地。 罗广明（百度） 据了解，2020 年的 Kubecon EU 的提案中，很少有涉及服务网格落地场景，由此来看，服务网格技术离大规模生产落地还有很远的路要走。当前 Istio 架构体现出来的性能问题迟迟没有得到优化，使用原生的 Istio 大规模上生产还不太靠谱

作者 | 徐迪、陈俊、敖小剑、宋进超 业界要闻 Apache Flink 1.10.0 发布 作为 Flink 社区迄今为止规模最大的一次版本升级，Flink 1.10 容纳了超过 200 位贡献者对超过 1200 个 issue 的开发实现，包含对 Flink 作业的整体性能及稳定性的显著优化、对原生 Kubernetes 的初步集成（beta 版本）以及对 Python 支持（PyFlink）的重大优化。 Linkerd 2.7 发布 此版本以安全为主题，主要更新亮点包括增加了将 Linkerd 的交叉 TLS 基础与外部证书发行商（如 Vault、cert-manager）集成的支持，改进了 GitOps 工作流，并使其易于自动轮换 TLS 凭据；还改进了 dashboard 的性能，提高了 Helm 图表的可用性。 上游重要进展 Kubernets 1.18 分支本周二正式创建了，code freeze 在 3 月 5 号； graduate PodTopologySpread to beta feature gate PodTopologySpread 升级到 beta 版本。 Provide OIDC discovery for service account token issuer 引入了新的 token issuer，符合 OIDC(OpenID Connect)