楼主想要的可能就是Serverless,目前K8s上最流行的serverless框架Knative的一个目标,就是降低应用在k8s上的部署难度,将所有的部署细节(实例数,网络路由等)隐藏,只需要一键部署业务代码...
貌似没有微服务和容器资源的使用相关的说法,消耗多少资源,这个和实际的业务有关,和微服务拆分没有直接的关系,也没有一个消耗多少资源合理的标准。一般微服务要求采用容器部署就是利于弹性扩展,可以设置一个阈值进行自动扩...
云平台上的应用日志,不建议和实例绑定,否则在容器迁移是,日志会丢失,建议通过日志平台进行统一收集管理
前提是微服务的规模有多大。中大规模的系统:从目前的技术趋势和以往的实践来看,微服务和容器化部署还是结合比较紧密的。微服务系统一旦上了规模,成千上万个服务实例的运维是一个很大的挑战。容器和容器编排正是解决多服...
一楼的回答应该已经很全面了,我来补充几点实践的:1 服务分层,将系统的功能进行分层,服务归属于前后中台,层间单向调用,有效控制调用深度2 数据耦合,对于需要跨机事务的拆分,要重点分析,是否可以通过服务功能的调整避免(如将两...
需要具体看需求,每个方案都有自己的优势和问题。如果存在和虚拟机混杂的部署,可以考虑一下新版本Openshift和VMware的方案
很多大拿一再强调,微服务不是包治百病的良药。微服务的目的是为了更快的响应需求和更好的水平扩展能力,如果不是特别看中这两点,采用基于开放服务的单体应用,可能会更合适。...
目前微服务的发展方向是ServiceMesh,目前基本确定是Istio项目,好处是应用不在需要关注服务注册发现,应用路由,链路监控等功能,关注于应用开发;支持不同的开发语言;局限性是和容器平台结合很紧,同时由于所有的应用路由都由平台...
微核心的银行核心,加分布式的外围是一个比较好的方案
在多个网络区域布署不同的容器集群,DMZ,业务区可以分别多套集群,做为多可用区,提高可用性
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30