我们这边开发微服务架构也是刚开始 目前的情况是基本都是已经是已经运行在线的系统,那如果我们现在准备重构,第一细粒度拆分,按照什么套路拆呢?是按照业务呢还是service呢?哪种情况横着拆哪种情况竖着拆?第二就是服务间的通信机制了。
收起以下仅代表个人观点:
感觉这是个没有标准答案的问题,如何拆?按什么套路来拆?问答这两个问题的基础一定要十分熟悉你的业务逻辑才行。微服务这东西,尤其是那种已经运行多年的老系统,一不小心就能拆出问题。
如果对云计算,对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这个项目,对于微服务的拆分就会更有底气些!