需要具体看需求,每个方案都有自己的优势和问题。如果存在和虚拟机混杂的部署,可以考虑一下新版本Openshift和VMware的方案
很多大拿一再强调,微服务不是包治百病的良药。微服务的目的是为了更快的响应需求和更好的水平扩展能力,如果不是特别看中这两点,采用基于开放服务的单体应用,可能会更合适。
目前微服务的发展方向是ServiceMesh,目前基本确定是Istio项目,好处是应用不在需要关注服务注册发现,应用路由,链路监控等功能,关注于应用开发;支持不同的开发语言;局限性是和容器平台结合很紧,同时由于所有的应用路由都由平台
微核心的银行核心,加分布式的外围是一个比较好的方案
在多个网络区域布署不同的容器集群,DMZ,业务区可以分别多套集群,做为多可用区,提高可用性
拆分的方法论还是有的,比如DDD,EventStorming等。方法是死的,人是活的,再好的方法也需要人来执行,这块对整个业务流程要求非常的熟悉,最好是架构师和业务人员一起做这块的划分。对于不是太复杂的系统,可以参考一下的方法:可以
对于证券的业务不是很熟悉,但是原理应该是差不多的。我们都知道,微服务的划分强调按照业务领域进行划分,每个服务是个业务对象。可以将系统的业务对象(这里的业务对象是业务人员的视角,不是开发人员的)进行归纳,记录每个业务
微服务的拆分的原则就是业务对象,业务对象,业务对象(重要的事情说三遍),为什么是业务对象,其中包含两层含义,一个是业务,一个是对象。业务要求拆分的服务应该能完成一个相对完整的业务功能,而不是一个业务的一个步骤;对象要求服
理论上,能够实现用户最终价值原则的拆分,是一种很好的方式。但是实际情况是很多时候按照这种方式进行拆分后,服务的很多功能可能是重复的,如果将这些功能独立成服务,那有违背了这个原则,不独立后续变更又不好维护。所以在这
可以大家一起讨论,一种做法是通过上层的云管理平台,为每个集群分配实例数,同时结合数据中心间的负载均衡策略,实现双活应用。在一个数据中心不可用时,需要通过云管,将实例转移到另外的集群。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30