a、在网上邻居上点右键-属性 ,然后在宽带连接上点右键-属性-高级-internet连接共享;
b、下面的都打上对勾,出现对话框选择"是",就可以了。
2、ip地址要改成19216801(共享时会提示修改ip),子网掩码2552552550,网关和dns都19216801;
3、客户机ip可以设置成自动获取,也可以手动设置成和主机一个网段,子网掩码和网关 和主机一样在主机上运行添加网路向导,选择局域网其他计算机通过本机连接到internet,然后就可以同时上网了使用docker-compose安装是最方便的
在/opt/目录下创建kong文件夹,然后创建一个docker-composeyml文件并编辑
在docker-composeyml添加如下配置(20220528亲测可用)
假设使用的是本地搭建
使用浏览器访问127001:1337
注:端口号在docker-composeyml中指定了1337
若是使用云服务器,注意做好DNS解析以及Nginx配置
这里给出一份可用的kongconf
使用浏览器访问kongYOUR_DOMAIN:1337
打开界面后,是要创建一个管理员账号的,按说明填写即可
先理解一下概念:
我们现在 *** 作的可视化平台是Konga
Konga通过调用Kong的admin url,对Kong网关进行配置管理
所以这一步我们需要将Konga和Kong搭上线
在Connection页面配置要管理的Kong网关
主要填写参数说明:
Name:必填,唯一,用于备忘
Kong Admin URL:Kong网关的管理路径,默认端口是8001,在docker-composeyml可修改对外暴露的端口号
这里有个提示很显眼:Kong's admin API should not be publicly exposed
故我们在云服务器部署时,都应该注意8001的这个端口不应随意暴露出去,以免发生黑客攻击风险
进入Service菜单,点击 ADD NEW SERVICE(添加新服务)
这里我们假设要代理某度的服务
主要填写参数说明:
Name:非必填,服务名称,用于备忘这是一个什么服务
Protocol:必填,填写>
最近开发了一基于springcloud的微服务架构的门户项目,因为客户对系统性能有要求,所以楼主对系统的一些api接口进行了大量压力测试。在压测过程中,发现接口的性能瓶颈之一是服务网关和数据库部署在虚机上,所以本文将分享内容分为两部分
性能压测思路是从软硬件负载 f5,nginx,到容器化平台k8s、docker、zuul网关,再到数据存储es、mysql、mongodb、redis,进行全面测试。
性能压测汇总
部分接口压测结果
其中值得关注的是,用一台zuul网关节点和一个业务节点压测空接口,发现一个有意思现象:
空接口压测不走zuul,一个业务节点tps能达到 32000, 走zuul网关,一个业务节点空接口tps只有11000,性能损耗64%。
当时就感觉zuul网关在我心中高大的形象碎了一地,但是没办法,性能不达标必须要优化。所以楼主查了很多资料,也问过一些docker和k8s的容器化平台大牛,总结出两点经验:
所以楼主向公司申请物理机,继续性能压测,当然这不是重点,重点是接下来要讲的:为什么服务网关和数据库不能部署到虚拟机上 。
虚拟机的特点
io开销
我们知道,不管虚机上部署了多少个应用,一旦涉及到数据的存储,如果采用虚机部署数据库,会带来不必要的网络io开销。因为虚拟机在调度大量物理的cpu和内存、特别是磁盘IO时,必须经过虚拟机和物理机两层网络io读写开销 *** 作,是非常耗系统性能的。
一般情况下,使用虚拟机部署应用,其性能衰减约20%左右,这不是优化代码能解决的。
共享物理机资源
因为虚拟机在cpu资源、网络等方面共享物理机资源,虚拟机之间会存在竞争物理机资源,造成程序不稳定情况。
docker容器部署
更要命的是,如果数据库和zuul网关部署到容器(实质也是虚拟机)里,那么网络io读写变成docker(虚拟机)到虚机,再到物理机三层访问,无形之中又增加了io读写性能开销。尤其是对于请求吞吐量要求很高的服务网关zuul,是不能容忍的。
所以虚机对于IO密集型以及对延迟要求很高的业务场景不合适。
另外,早期的时候,作为一名架构师需要尽早的规划好服务网关和数据库的物理部署方式以及软硬件性能要求。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)