作者回复: 课程准备中,下次课规划的是微服务案例+k8s+CI/CD相关主题,请保持关注,谢谢!
作者回复: 谢谢支持🌹加油💪
作者回复: 谢谢支持!加油!
作者回复: 你好,我没有直接接触过游戏架构,但我认为你的场景可以考虑采用支持http2的grpc协议,grpc支持长链接甚至双向流等高级特性。网关的话,envoy和http2/grpc配合比较好,其它如nginx/kong/traefik适当配置应该也支持。
作者回复: 谢谢支持!加油!
作者回复: 微服务可以简单分层,底层是原子(基础)服务,例如你讲的订单、商品和用户这些可以算作原子服务,上层是聚合服务,它根据具体业务场景的需要对底层服务进行聚合裁剪,并提供给具体应用展示,所以可以根据管理功能的具体需求,开发一个聚合服务。聚合服务也叫BFF,Backend for Frontend,专为前端展示而开发的微服务,在无线和单页应用场景下,常常需要开发很多聚合服务,以适应不同无线/单页应用的展示需求。
作者回复: 谢谢支持!后续课程正在准备中,敬请期待!
作者回复: 你好,你的问题都是开放性问题,也可以说是情景性问题,要看企业和业务上下文的,没有固定答案。比如对于初创公司,谋活第一位,可能根本不考虑上面的问题,怎么能搞定就怎来。但有一些基本原则,比如拆分,可以按照业务领域拆分(比如电商账户,商品,购物车,支付等),也可以根据团队边界进行拆分,实际业界一般都是根据业务域,同时考虑团队规模分工进行拆分,而且随时间会不断变化,所以拆分是个动态不确定的过程,现实世界没有一次性设计和拆分好的,这也就是微服务的演化性。关于调用方式,一般给UI用的前端适配层服务(也叫BFF)经常需要对后端服务进行聚合,而后端一些多步骤流程性(比如贷款审批流程)服务经常使用链式调用。分布式事务当前有很多方案,比如本地事务+消息机制和tcc这两种机制用得比较多,另外saga和事件溯源(event souring)等高级机制,这些都相对比较复杂和性能开销大,建议如果能够在架构设计上避免分布式事务,则尽量避免,采用最终一致方式是业界最佳实践。
作者回复: 你好,我主要经验是在携程/拍拍贷等公司使用过netflix zuul,目前我还没有直接使用过spring cloud gateway,这个东西比较新,暂时还没有关于其它公司使用的一手资料。建议求稳的话用spring cloud zuul,同时关注spring cloud gateway;当然你也可以尝试spring cloud gateway,需要多在测试环境中压测下。
作者回复: 你好,我的架构图制作基本上就用power point。对架构师来说,关键是抽象思维能力(心中有图),工具只是把它表达出来,不是重点。其它工具我所知的draw.io可以尝试下。
作者回复: 可参考我的公众号文章《BFF和网关是如何演化出来的》https://mp.weixin.qq.com/s?__biz=MzIxMTA5NjQyMg==&mid=2647802030&idx=1&sn=4779d09b22e6aa58825e1bd8f9811bb2&chksm=8f7c66a7b80befb182bed6aaba407a20f706f3f74c110b6e08da98b9e73654e7ef488a380cbb&mpshare=1&scene=1&srcid=011629lX0YKQDkOa85jefEcn&key=1c48b7b0ee5584b17b0999f15b6e7033890fa08ed7cdbcb171458d3bee52d2a88d0d1b65893d88a7744b5591f2fe6b717a6aeba0c6ccb0d05f21a804abd35b5fce04e20f402f2471efa838d490c5f820&ascene=0&uin=MjI5NTUyNTEwOQ%3D%3D&devicetype=iMac+MacBookPro11%2C4+OSX+OSX+10.14.2+build(18C54)&version=12010210&nettype=WIFI&lang=zh_CN&fontScale=100&pass_ticket=wY1KA6H1glycisTVYsYjEani%2FeDsAaXKPZnDKTlMMAsaaXbBe4xvVF1TPMR1EqnI
作者回复: 谢谢支持!加油🌹