1.本发明涉及微服务部署技术领域，具体为一种多版本控制的微服务开发 部署系统。
背景技术：
2.springboot为java系中最重要的微服务架构。由于目前主流的个人计算 机硬件和成本限制，多为16g，而通常一个微服务运行时占用内存350m
‑
1g不 等，当微服务数量会随着业务规模不断增长，单机调试的性能瓶颈出凸显出 来，同时启动服务的时间也会明显延长。若有多版本服务同时在线的需求， 单机几乎是不可能完成了。
技术实现要素：
3.本发明的目的在于提供一种多版本控制的微服务开发部署系统，以解决 上述背景技术中提出的将所有个人pc组成一个大型研发集群，共同提供计算 资源，同时集群内多版本微服务通信流量可控可监测的问题。
4.为实现上述目的，本发明提供如下技术方案：一种多版本控制的微服务 开发部署系统，其特征在于：搭建kubernetes平台为基础设施核心，利用 hyper
‑
v来虚拟化个人pc的计算资源，交由kubenetes调度，由maven插件 jkube调用dockerclient+kubectl来构建镜像和发布服务，弃用eureka和 config，由kubernetes的coredns和confirmaps来实现服务自动发现和配 置中心的功能，istio进行流量管理，实现多版本服务通信可控。
5.优选的，所述kubernetes平台的节点池分为两个部分：
6.稳定服务节点池，由服务器上的虚拟节点组成，将稳定版本微服务部署 在此节点池；
7.研发服务节点池，由研发个人计算机的虚拟节点组成，将开发版本的微 服务部署在此节点池。
8.优选的，所述kubernetes平台是由linux服务器和个人计算机共同组成 一个弹性伸缩的kubernetes集群。
9.与现有技术相比，本发明的有益效果是：本发明可将所有个人pc组成一 个大型研发集群，共同提供计算资源，同时集群内多版本微服务通信流量可 控可监测。
具体实施方式
10.下面将结合本发明实施例中的，对本发明实施例中的技术方案进行清楚、 完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部 的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳 动前提下所获得的所有其他实施例，都属于本发明保护的范围。
11.本发明提供一种多版本控制的微服务开发部署系统，可将所有个人pc组 成一个大型研发集群，共同提供计算资源，同时集群内多版本微服务通信流 量可控可监测；
12.搭建kubernetes平台为基础设施核心，利用hyper
‑
v来虚拟化个人pc 的计算资源，交由kubenetes调度，由maven插件jkube调用 dockerclient+kubectl来构建镜像和发布服务，弃用eureka和config，由 kubernetes的coredns和confirmaps来实现服务自动发现和配置中心的功 能，istio进行流量管理，实现多版本服务通信可控。
13.所述kubernetes平台的节点池分为两个部分：
14.稳定服务节点池，由服务器上的虚拟节点组成，将稳定版本微服务部署 在此节点池；
15.研发服务节点池，由研发个人计算机的虚拟节点组成，将开发版本的微 服务部署在此节点池。
16.所述kubernetes平台是由linux服务器和个人计算机共同组成一个弹性 伸缩的kubernetes集群。
17.实施例
18.服务注册与发现：
19.删除原有的公共服务eureka和config，由kubernetes的coredns和 configmaps替代。
20.在节省了资源占用的同时，也提升了服务的部署灵活性，不再受限服 务启动顺序的依赖和启动时间的等待，支持了多服务的混序启动；
21.服务调度：
22.将kubernetes的节点池分为两个部分：
23.稳定服务节点池，由服务器上的虚拟节点组成，将稳定版本微服务部署 在此节点池；
24.研发服务节点池，由研发个人计算机的虚拟节点组成，将开发版本的微 服务部署在此节点池；
25.利用kubernetes的nodeselector及nodeaffinity，确保服务合理运行 在预期节点；
26.服务labels：
27.labels是多版本共存的基础需求，它可以作为同一应用、不同版本的身 份标识，使得istio能正确将流量路由至对应版本；
28.example:
29.name:order
‑
v1
30.labels:
31.app:order
32.version:1.0
33.name:order
‑
v1.1
34.labels:
35.app:order
36.version:1.1
37.istio：
38.envoyistio会在每个pod中注入一个envoy，由envoy来全部接管每个 微服务的网
络流量；
39.example:
40.apiversion:networking.istio.io/v1alpha3
41.kind:destinationrule
42.metadata:
43.name:micro
‑
service
‑
account
44.spec:
45.host:micro
‑
service
‑
account
46.subsets:
47.‑
name:v1
48.labels:
49.version:"1.0"
50.‑
name:v2
51.labels:
52.version:"2.0"
53.virualservice.yaml；
54.example:
55.apiversion:networking.istio.io/v1alpha3
56.kind:virtualservice
57.metadata:
58.name:account
‑
service
59.spec:
60.hosts:
61.‑
micro
‑
service
‑
account
62.http:
63.‑
match:
64.‑
headers:
65.owner:
66.exact:cyang
67.route:
68.‑
destination:
69.host:micro
‑
service
‑
account
70.subset:v1
71.‑
route:
72.‑
destination:
73.host:micro
‑
service
‑
account
74.subset:v2
75.hyper
‑
v：
76.hyper
‑
v是windows系统本身自带的虚拟化应用。我们是通过hyper
‑
v创 建虚拟
机，桥接网络模式下，让虚拟机加入kubernetes集群，虚拟机的计算 资源也就可供kubernetes集群来调度使用。
77.启动docker服务时，增加网络监听方式：
‑
htcp://0.0.0.0:2375
78.docker：
79.在windows中安装docker后，直接使用hyper
‑
v虚拟机内的docker为 远程server端，本机为dockerclient，在系统环境变量中增加
ꢀ“
docker_host＝tcp://${vm
‑
ip}:2375”即可，以便于jkube直接调用虚拟机 内的docker完成镜像构建和推送的工作。
80.虽然在上文中已经参考实施例对本发明进行了描述，然而在不脱离本发 明的范围的情况下，可以对其进行各种改进并且可以用等效物替换其中的部 件。尤其是，只要不存在结构冲突，本发明所披露的实施例中的各项特征均 可通过任意方式相互结合起来使用，在本说明书中未对这些组合的情况进行 穷举性的描述仅仅是出于省略篇幅和节约资源的考虑。因此，本发明并不局 限于文中公开的特定实施例，而是包括落入权利要求的范围内的所有技术方 案。