如何把握基于传统业务的微服务化和容器化时划分的粒度?

因运营商对业务的稳定性和连续性有比较高的要求,故容器化和微服化的演进路径必然是从边缘业务到核心业务,从简单应用到复杂应用,过于简单、并发度低的系统其实不必要作微服务化。同时相对一般的企业,运营商的硬件投入更大,服务器性能更性。过小过细的微服化不利于发挥硬件性能...显示全部

因运营商对业务的稳定性和连续性有比较高的要求,故容器化和微服化的演进路径必然是从边缘业务到核心业务,从简单应用到复杂应用,过于简单、并发度低的系统其实不必要作微服务化。同时相对一般的企业,运营商的硬件投入更大,服务器性能更性。过小过细的微服化不利于发挥硬件性能。容器化并非包治百病的良药,某些对并发吞吐量要求更高的业务,直接运行在裸机上,通过系统调优提高性能,容器化未必是最好的选择。
故如何在运营商容器化和微服化过程中,更好地把握划分的最小粒度是运营商容器化和微服务的一个重要问题。
个人认为至少有以下原则:
1、高并发,多业务聚合的应该坚决拆成容器化、微服务。而低并发,业务相对单一的不需要;
2、高I/O,如文件转移服务的不需要;
3、允分考虑主机性能,以保证业务吞吐量为第一原则来考虑拆分的必要性的粒度。

收起
参与6

查看其它 1 个回答WilliamShen的回答

就经典微服务设计而言,领域驱动设计(Domain Driven Design)是微服务拆分的常用方法,一般而讲,一个微服务合适的粒度是,有一个所谓的'两个比萨饼'的规则。这个是亚马逊提出的,意思是说一个开发团队不能多到两个披萨饼还不够他们吃的地步,往往是5到7个人。

对运营商业务来讲,微服务改造是一个循序渐进、逐步演进的过程,微服务的粒度也是根据业务要求相决定,有时候一个服务的粒度可能比较大一点,不一定是微服务,也可以是小服务(mini service, 几个微服务组合在一起)。

软件开发 · 2019-12-26
浏览2707

回答者

WilliamShen 最近回答过的问题

回答状态

  • 发布时间:2019-12-26
  • 关注会员:3 人
  • 回答浏览:2707
  • X社区推广