云杉 NSP。缺点嘛,都没见过大规模投产。
按推荐顺序1、基于docker(一般)2、docker-compose(够用)3、mesos+marathon(挺够用)4、K8S(很够用,但学习成本高)
比如TIDB,融合了关系型数据库和非关系型数据库的技术特性,实现了高度兼容MySQL协议和生态、在线水平扩展、强一致分布式事务、多副本数据安全、实时分析等重要特性
自查八荣八耻以可配置为荣,以硬编码为耻以互备为荣,以单点为耻以随时重启为荣,以不能迁移为耻以整体交付为荣,以部分交付为耻以无状态为荣,以有状态为耻以标准化为荣,以特殊化为耻以自动工具为荣,以手动人肉为耻以无人值守为
这个方案挺好的,我们也着手在往这个方向做。F5-->NGINX*2--->APP-->DB
用nodeport模式这事儿会比较好推
这个问题的答案应该有业务特性决定。个人认为,生产应用少于20种,节点少于50个,发布频率低于每月2次的,没必要使用。
1、macvlan CNI,原生用法比较弱,需要做集中化ipam改造2、deployment加环境变量参数,微服务的注册中心可以支持应用自上报的IP PORT
数据库类不要用容器,获益不多,烦事不少
在真实生产环境下,替代和融合都困难,有一定开发改造量,而在平台之上独立部署微服务架构较好。当然也有尝试做融合的,看到鹅厂有投入精力做注册中心同步。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30