内容简介:所有的表现形式都是ip+端口的形式。
服务发现
所有的表现形式都是ip+端口的形式。
-
传统服务
>服务比较少的话,可以通过下面的方式。如果服务很多的话,基本运维人员都崩溃死了。
-
微服务
>服务太多的话,需要一种服务发现的机制。
- 客户端的发现
- 服务端的发现
部署更新和扩容
-
传统服务
>适合小项目,服务少,服务器少。
- 新服务的部署,代码写好,内网测试通过,上线,跟运维交涉那台服务器比较空闲,资源比较吃紧的情况,需要等待服务器到来在进行部署。服务器有了告诉运维将那个应用拷贝到我们的服务器上,可能通过ftp或者是自动化的方式,如果是web方法会需要拷贝一个tomcat分配一个端口号。查询服务器那些端口被用了,找一个没有被占用的,跟你的域名做域名解析,修改nginx,反向代理指向刚才的tomcat上。
- 更新直接ftp或者自动化更新下旧代码,直接用新代码更新就可以了。
- 任何应用都是2个实例,让服务高可用,所以更新代码的时候需要更新2次。下线一台,更新代码,上线。如果自动化做的不太好的话,基本人工成本很高
- 扩容跟部署一样都比较麻烦。
-
微服务
>服务数据居多,更新上线频繁。微服务如何解决这些问题呢
什么是服务排版,服务的发现,服务部署,服务更新,扩容,简化。
流行的服务编排工具
可以解决微服务遇到本节问题的解决
- Mesos
- docker swarm
- k8s
PS:抛出微服务的解决方案了,之后继续学习吧。
>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 一文读懂区块链链上扩容和链下扩容
- golang内存扩容
- Sharding扩容方案-2(实现)
- golang 切片扩容的探讨
- VirtualBox 虚拟机磁盘扩容
- VirtualBox中Ubuntu扩容
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。