1.C#能否做游戏全栈？基于云原生的源码一些新思考..
2.2024 开源之夏｜Hi 同学，快来认领你的源码开源任务！
3.阿里雷卷：3个软件开发最新趋势解析
4.Dapr在Java中的源码实践 之 服务调用
5.CA 周记 - 记我的 Windows Dev Kit 2023 使用体验
C#能否做游戏全栈？基于云原生的一些新思考..
上家公司解散后，我入职了新公司，源码负责研发效率和DevOps。源码我常常参与从前端、源码蜜桃影院大米原版源码后端、源码美术、源码策划、源码质量保证、源码产品管理等所有流程的源码重新组织，制定标准，源码实现自动化，源码提高工业水平。源码每个公司的源码具体情况和所需人员各不相同，这让我有时间复盘过去项目的技术债务。这篇内容是我在思考“C#是否能做游戏全栈”的新见解。
首先，我无意引起语言之争，也不是在推广“Web方案、Java”的概念，标题中的词语并不是为了炫耀或贬低任何技术。对我来说，技术方案和语言只是工具，所以我不自称是C#或Go的专家。随着云原生、容器技术的发展，整个后端工业化和生态的进步，我开始重新思考“C#现在能否做游戏全栈开发”。
技术选型从来不是个人喜好或语言优劣的问题，而是对项目负责时需要综合考量的复杂决策。
云原生是什么？简单理解，它指的是在云环境下的软件开发、部署和管理的方法，包括容器化、微服务、服务网格等技术。我会在后续内容中详细解释其优势。
本文的目标是探讨Unity前端是否能使用C#构建一套“分布式游戏系统API服务器”。讨论将聚焦于游戏系统的API接口，如登录、签到、养成、抽卡等，暂不涉及游戏玩法同步部分。
在之前的项目中，我们采用了一种类似于明日方舟的二游结构，弱联网，游戏玩法和战斗可以在服务器验证后再结束。为了应对首日用户量的激增，我们设计了最高万QPS和万注册规模的目标。项目主要架构包括SpringCloud + 微服务 + Serverless + 无状态架构 + .NET Core战斗验算，托管在阿里云的Serverless K8s服务上。虽然Java作为业务接口开发的玉石竞拍源码工具，但在分布式架构方面，我们更多依赖K8s本身，较少使用SpringCloud相关技术栈。
无状态架构带来的好处是，每个请求处理节点的结果相同，所有业务节点可以进行弹性扩展，故障节点可以快速恢复。Serverless架构也极大降低了运维成本，提高了整体服务的高可用性。
这种架构适合于明日方舟、这类弱联网游戏，或者像LOL、王者荣耀、雀魂这类大厅和游戏玩法、战斗分离清晰的游戏。在微服务架构下，可以进一步细分场景、战斗、房间逻辑等节点。
对于已有成型方案的项目，无需再做过多调整。
对于为什么在之前的项目中不使用C# / .NET Core，以及全栈开发的需要和全栈开发者的要求，我进行了复盘。在项目中，我将人员分为专业后端工程师和CURD员，后者负责基本接口编写。在资源有限的情况下，我们通过Unity客户端承担一部分全栈工作，即负责UI系统的接口编写，如卡牌数据、抽卡、结算等，但不负责过于复杂的模块，如账号系统、登录注册、游戏玩法等，这些复杂模块交由专业后端处理。
全栈开发者的需求是%前端技术和%后端技术的组合，以提高整体效率。引入GraphQL或APIJson等技术框架，减少接口数量，配合DevOps流程来保证接口稳定性。
为什么开始考虑C#？一方面，对于Unity前端的开发者来说，C#是一个重要选择，因为它可以减少语言切换的障碍。另一方面，基于C#构建分布式架构变得更容易，这要感谢云原生的发展。在之前项目中，我们最初使用SpringCloud，后来发现基于K8s本身构建分布式架构更为合适。怎么用游戏源码云原生为后端生态系统带来了共享优势，降低了对单一语言的依赖。
如何保证接口稳定性？在微服务架构中，确保全栈开发者编写的接口服务稳定即可。在Serverless架构下，每个接口稳定是关键。测试覆盖率需要达到%以上，每次修复错误时提交单元测试，进行代码审查、数据库结构审查、定期的CI测试和压测等。
综上所述，C#做游戏全栈开发似乎可行。基本架构可以采用k8s + Dapr + .NET Core + DevOps + APIJson / GraphQL（也可以选择任何语言）。
对于架构的理解，微服务不仅是一种设计方法，更是一种包含协作、沟通、团队管理和标准规范的架构。其核心特征包括围绕业务能力构建、分散治理、产品化思维、数据去中心化、容错性设计、演进式设计和基础设施自动化等。在新的项目技术栈上，我将采用C#作为业务接口编程语言，并推动全栈执行。后续会分享更多详细信息。
最后，我拥抱大云原生时代。
开源之夏｜Hi 同学，快来认领你的开源任务！
在这个夏天，SOFAStack 和 MOSN 再次参与开源之夏，带来了六个令人兴奋的项目任务！
开源之夏是由中国科学院软件研究所发起的暑期开源活动，旨在鼓励在校学生参与开源软件开发与维护，培养更多开发者，促进开源社区成长，助力开源软件供应链建设。
参与开源之夏，学生能利用暑假时间在开源项目中锻炼，提升技术能力，了解开源文化，结识行业前辈。成功完成并结项的同学将获得丰厚现金奖励和荣誉证书。
本次开源之夏由Koupleless、SOFARPC、MOSN和Layotto四个开源社区发布任务。
Koupleless专为解决企业研发、协作与资源成本等问题而设计，提供模块化应用架构，烟花爆单源码让用户以较低成本享受Serverless研发模式带来的优势，包括快速构建、秒级部署与调度。
SOFARPC是蚂蚁集团开源的一款高性能Java RPC框架，适用于应用之间的点对点远程服务调用，具有高可扩展性与生产级特性。
MOSN是一款云原生网络代理平台，由Go语言开发，具备高性能与易扩展性，支持多协议、模块化、智能化与安全特性，可与Istio集成构建Service Mesh，也可作为独立的负载均衡、API Gateway或云原生Ingress。
Layotto是一款使用Golang开发的应用运行时，旨在帮助开发者构建云原生应用，简化应用与基础设施的解耦，提供分布式能力，如状态管理、配置管理与事件订阅。
今年的Koupleless、SOFARPC、MOSN和Layotto项目为学生提供了六个机会，完成结项者将获得至元的奖金与荣誉证书。
具体项目包括：
Koupleless模块化研发框架中的“存量应用自动改造成模块”项目，目标是建设相关能力，帮助存量应用以较低成本转换为模块。导师：苟振东，邮箱：gouzhendong.gzd@antgroup.com，项目难度：进阶，技术领域：Spring Boot、DevOps。
Koupleless模块打包插件gradle版本项目，目标是完善SOFAArk打包插件以支持gradle版本。导师：梁栎鹏，邮箱：lianglipeng.llp@antgroup.com，项目难度：进阶，技术领域：Spring Boot、DevOps。
SOFARPC动态配置能力完善项目，目标是梳理并完善动态配置能力，支持更多配置中心，如Nacos、ZooKeeper。导师：刘建军，邮箱：evenljj@.com，项目难度：进阶，技术领域：ZooKeeper。
HTNN控制器支持更多服务发现（如Consul、Nacos v2）项目，目标是增强HTNN平台服务发现能力，支持更多系统。炒谷指标源码导师：罗泽轩，邮箱：spacewanderlzx@gmail.com，项目难度：进阶，技术领域：HTTP、Cloud Native。
Sentinel-golang流量控制能力集成进MoE（MOSN on Enovy）生态项目，目标是将Sentinel生态引入MoE生态中。导师：付建豪，邮箱：fujianhao.fjh@antgroup.com，项目难度：进阶，技术领域：HTTP、TCP/IP。
Layotto对Dapr依赖项目，目标是升级Dapr兼容版本至v1..0。导师：王文学，邮箱：wangwenxue.wwx@antgroup.com，项目难度：基础，技术领域：Programming Language、Dapr。
项目申报阶段从4月日至6月4日，学生可选择项目，与导师沟通并提交项目申请。学生报名截止时间为6月3日: UTC+8，项目申请书提交截止时间为6月4日: UTC+8。对上述四个项目感兴趣的同学们，可以直接联系导师或扫码添加SOFA小编，共同开启开源之夏。
欢迎加入开源社区，一起开源，一起成长！
项目申请入口：summer-ospp.ac.cn/org/o...
搜索SOFAStack/MOSN，即可查看或报名参与Koupleless、SOFARPC、MOSN、Layotto发布的项目任务！
阿里雷卷：3个软件开发最新趋势解析
欢迎来到极客视角的深入解析</，今天我们将一同探讨阿里云原生团队资深技术专家雷卷（陈立兵）在直播中分享的软件开发三大关键趋势——Service Mesh、FaaS和代码智能。Service Mesh：革新服务连接
Service Mesh在当前技术潮流中占据着核心地位。尽管Istio+Envoy的Sidecar架构仍是主流，但Dapr以其独特的设计理念崭露头角。Dapr的Sidecar不仅仅是个简单的代理，它能协助开发者应对跨语言应用开发的挑战，如处理不同SDK的不稳定性。例如，当大数据应用如HBase、Hadoop的Java SDK不支持所需语言时，Dapr Runtime能无缝集成gRPC和Kafka，无需开发者深入通信协议细节，简化了开发者的工作。 阿里巴巴正尝试引入RSocket Broker，基于Reactive Mesh，它提供了更全面的通信协议选择，与传统的Sidecar架构有所区别，尤其在处理事件驱动应用时，RSocket Broker更具优势。FaaS：灵活应用部署
企业中长尾应用的需求催生了FaaS的兴起。FaaS的优势在于能够将小功能部署到边缘，如CDN节点，避免了大而全系统的维护复杂性。FaaS通常配合Message+EventDriven的通信方式，gRPC因其快速响应的特性被广泛应用。新兴的AsyncAPI则支持代码自动生成OpenAPI，而FaaS与WebAssembly的结合解决了等待时间问题，Deno成为支持WebAssembly的良好Runtime选项。代码智能：提升开发效率
在技术架构之外，代码是架构实现的关键。代码生成技术，如IntelliCode、Codota、Kite等，能快速生成代码框架，提高开发效率。然而，技术的快速迭代也要求开发者依赖于Cloud IDE，因为它们能更快地适应新需求，如跟进新框架和新技术。 以上是雷卷在直播中对当前软件开发趋势的深度剖析，如需了解更多关于领域驱动设计、Reactive和RSocket的见解，不妨点击原文链接，深入探索。Dapr在Java中的实践 之 服务调用
服务调用机制通过标准协议（gRPC或HTTP）允许服务间通信。
Dapr引入边车（Sidecar）模型，服务与自有的Dapr实例通信。部署后，Dapr实例互相发现，实现服务间的通信。
创建两个SpringBoot应用，分别命名为invoke-server与invoke-client。两者通过Dapr进行调用。
编写invoke-server项目以响应send接口。实现InvokeRequest和InvokeResponse类，配置application.properties文件。
在invoke-client应用中，利用依赖注入DaprClient，并调用invoke-server的接口。编写代码实现InvokeRequest和InvokeResponse的交互。
应用启动前需进行Maven打包操作。
运行invoke-server和invoke-client服务，Dapr Dashboard显示服务运行状态。
访问localhost:/say?参数验证调用流程，确认服务调用无误。
使用名称解析组件（Kubernetes或mDNS）解决服务发现。对于Kubernetes集群，利用其DNS服务。
自托管环境中，使用mDNS名称解析组件。
部署Consul作为名称解析组件，添加相应的配置并重启服务。在Consul中监控服务注册状态。
需注意，Consul名称解析组件仍处于实验阶段，谨慎用于生产环境。
详细配置信息请参阅相关文档。
CA 周记 - 记我的 Windows Dev Kit 使用体验
在过去三十年，x架构的计算机主导着我们的日常生活和生产工具。然而，随着移动终端的普及和应用场景的演变，低功耗、高性能且体积小巧的设备，如智能手机、平板、笔记本电脑以及物联网设备，正在逐渐取代传统的x设备。这些设备采用与传统x设备不同的指令集。这是未来几年的增长点，各厂商正纷纷尝试在ARM架构上开发不同的终端产品。在上周，我收到了微软的Windows Dev Kit ，下面我将分享这几天的使用体验。
从开箱开始，微软并不是年才涉足ARM设备领域，最早的ARM设备可以追溯到十年前的Surface RT。十年前的Surface RT是一款非常前瞻的产品，但由于系统架构和软件生态的限制，在推出了两代设备后就暂停了更新。很多人认为，软件生态的不完善是Surface RT失败的关键。那么，这一代的Windows Dev Kit 又带来了哪些不同呢？
开箱后，我看到了Windows Dev Kit 的硬件设计，它小巧便携，放在桌面上几乎不占空间。设备接口齐全，包括3个USB A、2个USB C、1个mini DP、一个RJ 网口，以及一个瓦的电源适配器。设备正面的田牌LOGO也显而易见，这表明它是一款微软出品的设备。作为一款开发者套件，它在外观设计上已经非常友好，配置方面，搭载高通骁龙8cx Gen 3处理器，内存为GB，存储空间为GB NVMe，完全能满足体验和开发的需求。从价格来看， RMB的售价对于厂商或个人开发者来说都非常友好，这也体现了开发者套件的价值所在。
在软件生态方面，软件生态是至关重要的，再好的硬件设备若没有软件生态的支持，将会是徒劳无功。微软的Surface RT就是一个很好的反例，不支持exe程序的运行是其最大的遗憾。在激活Windows Dev Kit 开发者套件后，我进行了深度体验，以了解其在软件生态上的改进。
Windows Dev Kit 搭载的是Windows on ARM版本。在“设置 > 系统 > 关于”中，可以看到与硬件和系统相关的信息。体验下来，这个ARM版本的Windows 与x版本几乎一致，一般用户在使用该套件时，几乎不需要任何过渡成本，不会像Surface RT那样在软件体验和系统变化上产生巨大的差异。
在软件方面，与十年前不同，这次的软件可以运行exe程序。这是非常重大的进步，因为exe文件影响了Windows用户多年。此外，它是向下兼容x的位或位结构，如微信、QQ、腾讯会议等日常应用都可通过exe进行安装。通过任务管理器查看后台运行情况，可以看到既有原生Arm应用，也有x应用。在兼容性上，Windows 表现得非常好，得益于x的模拟技术，x应用的丰富生态系统在Arm上可用。这使得用户无需对应用进行任何修改，就能获得运行现有x win应用的体验。应用甚至可能不知道它在Arm电脑上的Windows上运行，除非它调用特定API（IsWoWProcess2）。此外，WOW层Windows允许x代码在Arm版本的Windows上运行。x仿真的工作原理是将x指令块编译为具有优化功能的Arm指令，以提高性能。服务会缓存这些已转换的代码块，从而减少指令转换开销，并可在代码再次运行时实现优化。每个模块生成的缓存，使得其他应用在初次启动时就能使用这些缓存。
向下兼容性是关键，它为系统迁移提供了重要保障，也是微软吸取了Surface RT教训的结果，同时也是对现有软件生态的承诺。
在Arm原生应用生态方面，向下兼容只是一种过渡策略，是否有软件厂商为Arm的Windows开发应用呢？这是更重要的事情。作为一个开发者，我观察到浏览器方面，除了微软自家的Microsoft Edge已经是原生应用，Firefox和Chromium也已原生支持，对于Chrome，我预计只是时间问题。会议系统方面，Microsoft Teams和Zoom已经是原生应用，至于腾讯会议则还在开发中。办公应用Microsoft 已经是Arm原生。其他社交类软件和工具类软件还在适应原生软件的阶段，我惊喜地发现VLC Player也已经原生支持。作为一款开发者套件，Visual Studio、Visual Studio Code等常用工具也是原生支持的。因此，在工作和生活所需中，原生应用的覆盖率达到了%甚至%阶段，这是一个令人满意的结果。毕竟我在三年前经历了Apple Silicon的转变，当时的原生应用较少。这是一个良好的开始，也期待更多的软件制造商充分利用Windows Dev Kit 开发出体验更好的原生应用。
生态完整不仅关注桌面应用，Web应用和Progress Web App（PWA）也是一个不错的选择。现在，Web应用非常强大，在互联网环境下，PWA也可以为软件生态提供补全。我可以通过PWA将常用的社交平台应用安装到本地，如石墨等日常工作也可以通过PWA安装到本地，这为混合应用的互联网开发商提供了很好的支持。
Windows Dev Kit 面向开发者，自然有一套完整的开发者工具链。从编程语言、开发工具和框架，以及应用场景三个方面，我将与大家分享。
编程语言方面，对于不同语言编写的应用，Windows on Arm已经提供了很好的支持，如.NET 6/7，Java（Microsoft Open JDK 或），Python 3.，以及VC++ Runtime等都有相关原生支持。这为使用不同语言的开发者提供了极大的便利。编程语言只是第一步，兼容和扩展相关的库需要更多开发者的努力。
开发工具和框架方面，原生支持的开发工具包括Visual Studio on Arm和Visual Studio Code。Visual Studio Code在功能完整度上更胜一筹，我常用的如远程调试、Python/.NET/Java/NodeJS/Rust组件都没有问题，还有Markdown工具和PDF工具也都没有问题。我重点介绍Visual Studio on Arm，你会发现安装时与x版本有所不同，很多模板支持缺失，包括Azure、.NET MAUI、Python开发等。这比较正常，因为Windows Dev Kit 当前的主要任务是解决Windows桌面生态和开发场景。然而，一些框架如.NET MAUI，我尝试使用一些特别的方法实现了调试，分享给大家，以便在Windows on Arm上优化跨平台应用。
应用场景方面，在官方文档中，你可以看到关于AI的应用，通过堆叠多台Windows Dev Kit为AI模型结合Azure进行处理，或者通过本地NPU能力完成模型推理工作。低功耗、高性能的ARM设备在未来将成为重要的边缘设备。
有小伙伴问，除了桌面和AI，还有云原生吗？实际上，WSL 2就是一个云原生环境，你可以在此完成更多云原生操作。Linux在Arm上的开发工具链非常完善，你可以通过WSL 2配置Docker、Dapr、K3s，以及与数据科学、机器学习相关的能力，以及Azure配套的CLI。作为开发者套件，Windows Dev Kit 无疑是完美的。
总结而言，Windows Dev Kit 正式开启了Windows on ARM的软件生态之路，这是非常重要的一步。开发者优先是微软ARM战略中的关键部分，希望更多厂商和开发者尽快投入到Windows on ARM的研发中，为下一代计算终端提供更好的支持。
相关文档