java scheduler 粒度_微服务架构按照什么细粒度拆分？

以下仅代表个人观点：

感觉这是个没有标准答案的问题，如何拆？按什么套路来拆？问答这两个问题的基础一定要十分熟悉你的业务逻辑才行。微服务这东西，尤其是那种已经运行多年的老系统，一不小心就能拆出问题。

如果对云计算，对OpenStack有了解，建议以OpenStack中的Kolla项目为微服务入门学习对象，Kolla干的事情就是把OpenStack服务拆分成微服务的形式跑在容器中，OpenStack号称全球最大开源Python项目，由几十个开源子项目组成，如果能把这样复杂的集群项目都拆分成微服务，那么一定会得到很多别人给不了的心得体会。

这里以OpenStack为例，Kolla这个项目对OpenStack的拆分，大概如下：

1、先按服务功能划分，得到粗粒度，如计算服务、网络服务、存储服务，这些租粒度模块通常会共享同一个base镜像，这个base镜像中预置了服务模块的共性依赖；

2、基于服务模块的“原子性”拆分，如把计算服务Nova拆分为noav-api、nova-scheduler、nova-compoute、nova-libvirt等等，所谓原子性拆分，就是拆分到不能再往下拆为止，原子拆分后通常就是彼此独立的单进程了，也可以把他们称为是叶子节点了，他们的镜像都是针对自己依赖的“个人”镜像，不能被其他进程共享了。

如果从镜像的角度来看，大概是这样：

父镜像：centos-base

一级子镜像：centos-openstack-base

二级子镜像：centos-nova-base

叶子节点镜像：centos-nova-api

这几个镜像的继承关系是这样的：centos-base->centos-openstack-base->centos-nova-base->centos-nova-api

以上只是举个例子供参考，建议深入了解下Kolla这个项目，对于微服务的拆分就会更有底气些！收起