云网络由物理网络和虚拟网络共同组成，两者都会影响网络性能。过去的研究主要集中于解决物理网络探测，而在虚拟网络探测领域的相应研究则较少。本文将为大家分享一种专为大规模多租户虚拟网络设计的主动探测系统Zoonet，从技术层面解读Zoonet系统的设计背景、面临挑战、技术架构，以及大规模部署的经验分享。
2022 年，架构领域发生了哪些值得关注的事情？一位架构师必备哪些技能？2023年哪些架构趋势需要掌握？Nacos 和 MSE 创始人、阿里云高级技术专家彦林做客 InfoQ 直播间，为我们带来 2023 年的架构师发展指南。
之前看过杨振宁的一个采访，说他最大的成就，不是获得了诺贝尔奖的研究，而是之前的一个普通理论的研究：他坚信事物是遵循一定规律的，不是大家认为的不可捉摸，花了7年时间，陆陆续续，终于找到了一个很好的解释，并且幸运的是，这个研究结果可以覆盖非常多的场景。 当我看到这个采访的时候，内心触动到的一个点是：尝试寻求表象背后的规律或者通用解释，是能够帮助更多的人、产生更大的影响的，这也应该是我们应该努力并坚持的方向。
最近同事说到 Java 的ParallelGCThreads 参数，我翻了下 jdk8 的代码，发现 ParallelGCThreads 的参数默认值如下： 如果 cpu 核心数目少于等于 8，则 GC 线程数量和 CPU 数一致 如果 cpu 核心数大于 8，则前 8 个核，每个核心对应一个 GC 线；其他核，每 8 个核对应 5 个 GC 线程 但是被提醒，发现即使在分配 4 核的容器上，GC 线程数也为 38。然后就想到应该和容器的资源限制有关—— jvm 可能无法觉察到当前容器的资源限制。 翻了下代码，发现最新版本的 java 是能感知容器的资源限制的，就按照jdk版本再翻了下代码。
站在 2023 年的今天，Service Mesh 早已不是一个新兴的概念， 回顾过去 6 年多的发展历程，Service Mesh 从一经推出就受到来自全世界的主流技术公司关注和追捧。 2016 年作为 Service Mesh 的元年，Buoyant 公司 CEO William Morgan 率先发布 Linkerd[1] ，成为业界首个 Service Mesh 项目，同年 Lyft 发布Envoy[2] ，成为第二个 Service Mesh 项目。 2017年，Google、IBM、Lyft 联手发布了 Istio[3]，它与 Linkerd / Envoy 等项目相比，它首次给大家增加了控制平面的概念，提供了强大的流量控制能力。经过多年的发展 Istio，已经逐步成为服务网格领域控制平面的事实标准。 2018年7月，Istio 1.0版本发布[4]，标志着其进入了可以生产可用的时代，逐渐也有越来越多的企业开始考虑和尝试将服务网格应用于生产中。 Istio 作为当前最流行的开源服务网格技术，它由控制平面和数据平面两部分构成。
阿里巴巴中间件陪伴大家又是一年了，春节即将到来，我们不禁回望，这一年我们留下了什么，又收获了什么。 翻阅着一篇又一篇的稿件，细数着往日的场景，2022年我们共发布了151篇文章，是各位读者的厚爱，让我们能持之以恒地与大家分享云原生和中间件的每一点变化。在这些内容中，我们看到了技术人员对精进自身的渴望，也看到了大家解决问题的思路，更能感受到大家对产品和技术的热情与真挚，以及遇到新开源项目时的兴奋与期待。因此，当我们按下「发布」时，希望能不负每一位开发者的等候。 我们选取部分内容，带大家重温过去一年的好文章。
现在，领导要响应集团提高代码质量的号召，需要提升单元测试的代码覆盖率。当然，我们不能让领导失望，那就加班加点地补充单元测试用例，努力提高单元测试的代码覆盖率。至于单元测试用例的有效性，我们大抵是不用关心的，因为我们只是面向指标编程。 我曾经阅读过一个Java服务项目，单元测试的代码覆盖率非常高，但是通篇没有一个依赖方法验证（Mockito.verify）、满纸仅存几个数据对象断言（Assert.assertNotNull）。我说，这些都是无效的单元测试用例，根本起不到测试代码BUG和回归验证代码的作用。后来，在一个月黑风高的夜里，一个新增的方法调用，引起了一场血雨腥风。 编写单元测试用例的目的，并不是为了追求单元测试代码覆盖率，而是为了利用单元测试验证回归代码——试图找出代码中潜藏着的BUG。所以，我们应该具备工匠精神、怀着一颗敬畏心，编写出有效的单元测试用例。在这篇文章里，作者通过日常的单元测试实践，系统地总结出一套避免编写无效单元测试用例的方法和原则。
可能大家谈到低代码想到更多的是低代码搭建页面的平台，内部不少也是此种，其实对于偏逻辑编排、服务 BaaS 能力的偏可视化方式其实也算低代码，旨在「通过少写代码，用更便捷的方式来实现原本需写代码的工作」。 说到低代码，喜欢的人特别喜欢，不喜欢的人很不喜欢，此外也有“假装”去喜欢的，也有喜欢得不明不白的，我现在对于低代码是有点儿喜欢的那种，不过只限于「在特定领域，实现需求的速度比熟练工程师写代码要快的场景」，这种场景下用起来真心会比较爽，可能也用得不爽的时候，但是这种不爽远小于他带来的效益减去原本敲代码的投入，也很值得将这类产品做到好用爱用。 其实低代码产品是比较难做成的，特别是大而全的那种，由于考虑因素过多，导致步调很慢，也很难做到很易用，导致一边投入很大，一边又急切上线落地使用，从而出现平台方觉得投入很苦，使用方觉得不太好用还需吃狗粮的矛盾，往往需经过忍耐很长时间才可「守得云开见月明」，不过很多都在没有见月明的时候就奄奄一息了。反而专门领域的比如说表单、表格、图表低代码搭建活的很不错。还有一些 BaaS 类单领域的活得也还可以，我个人更偏向「易用的可很轻快解决对应领域问题低代码产品
