共计 1075 个字符，预计需要花费 3 分钟才能阅读完成。
BoCloud 博云微信公众号【你问我答】小栏目，将收集和整顿企业在 IT 建设所遇到的问题与难题，由博云产品与技术团队进行针对性答复，每周五通过【你问我答】栏目进行公布，心愿能为企业 IT 建设提供思路与办法。无论您是哪个行业的 IT 建设者，如果您有在容器云平台建设、微服务架构转型、DevOps 平台建设、多云治理平台建设等技术方面所遇到的问题，欢迎您间接评论留言发问。
以下是本周问题精选：
网友 1：现有的利用不是微服架构，有必要做革新吗？
博云产品团队 ：其实应用微服务架构还是应用本来的单体架构，都取决于需要，那么问题就是咱们目前是什么样的需要。须要微服务架构的，个别面临以下几个需要：
- 更新迭代太快，而部署麻烦，每次都要花费很长时间，常常影响业务。
- 公司的利用有几十个，反复的模块很多，也无奈对立治理，将来还有扩大的需要。那就不如趁早转微服务架构，另外须要一套服务治理平台。
- 利用中某模块应用频繁，并发率很高，或有高峰期，常常须要资源的扩容缩容，单体利用做集群部署勉强能满足，但运维老本翻倍回升，且可用性降落。
网友 2：微服务和容器之间是什么关系？
博云产品团队 ：刚接触容器的人，能够将容器与虚拟机类比来看，那么微服务是部署在容器中，或虚拟机中，或物理服务器中，都是能够的。
然而容器有其独特的劣势，疾速启停，独立过程等，能够补救很多的微服务运维上的毛病，所以两者能够说是黄金搭档。
然而两者自身没有依赖性，都是独立的货色，只是两者的理念联合，会更加完满。
网友 3：微服务框架部署时的业务连续性如何思考？
近年金融行业，尤其是银行业监管越来越严格，对业务连续性要求的更高，银行零碎对于由传统架构迁徙至微服务有较迫切的需要，目前在理论部署零碎时，个别须要思考零碎的同城双活或同城、异地多活，以保障业务连续性。
那么在迁徙至微服务架构的过程中，微服务架构上对于双活、多活的需要是如何思考的？如何实现异常情况下疾速无中断切换、不同核心间数据一致性等问题是否有解决倡议？
博云产品团队 ：这个问题绝对简单一些，须要思考 IDC 的建设计划，网络计划，数据存储计划等。这不仅仅是微服务可能解决的问题，微服务只能解决业务单元拆分开发的问题。
网友 4：某些业务场景下会存在不太好熔断的状况，那这些场景是否有好计划能够实现熔断机制？
举例来说：保险客户下单，须要前端出单零碎查问客户的一些指标信息，来作为计算保费进行报价的根据，这种相似场景是否有好的计划能够实现熔断机制？
博云产品团队： 能够思考间接在网络层实现，依据呈现零碎的返回后果做信息匹配，如果不满足要求，间接触发熔断操作，能够参考服务网格的实现形式。
