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

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

2回答

朱祥磊朱祥磊  系统架构师 , 某移动公司
zhuhaiqiang赞同了此回答
微服务并不是越小越好,数量不宜过多,需要充分考虑到功能复用性、压力、开发工作量、团队等因素,以敏捷开发为原则。显示全部

微服务并不是越小越好,数量不宜过多,需要充分考虑到功能复用性、压力、开发工作量、团队等因素,以敏捷开发为原则。

收起
 2019-12-26
浏览785
就经典微服务设计而言,领域驱动设计(Domain Driven Design)是微服务拆分的常用方法,一般而讲,一个微服务合适的粒度是,有一个所谓的'两个比萨饼'的规则。这个是亚马逊提出的,意思是说一个开发团队不能多到两个披萨饼还不够他们吃的地步,往往是5到7个人。 对运营商业务来讲,微服务...显示全部

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

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

收起
 2019-12-26
浏览801

提问者

郭维项目经理, 广东联通

问题状态

  • 发布时间:2019-12-25
  • 关注会员:3 人
  • 问题浏览:1580
  • 最近回答:2019-12-26
  • 关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
    © 2020  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30