在可观测性方面,EBPF技术用于容器的安全检测目前也是一个方向。
一般会选择网关,网关作为内外部交互的连接点,一般外部的服务访问,建议通过网关进行鉴权。内部服务之间的调用,如果是一个分布式应用系统内服务的调用,则一般不做鉴权。若确实有鉴权的必要,建议可构造一个权限中心。
目前应该很多金融企业都会采取双模IT的形式,也就是敏态和稳态并行的形式。对于一些有特定背景,并且适用于敏态的项目,也都会推进使用敏态建设模式。对于一些关联复杂,重大的项目,或采取稳态较多。我觉得这个不涉及调和的问
大概能明白这个意思,比如JEE里面有些组件要依赖IP地址做集群的同步之类的,但是容器环境下IP地址是变化的(非MACVLAN这种),部分组件的使用就会有一定问题。 一般这种我们是建议应用做改造的,比如使用CRONJOB资源的形式去做
还是要根据企业的实际情况来确定吧。 DEVOPS推进可能比较深入的企业,在OPS阶段就可以通过自动的一些工具,配合机制反馈给下一个迭代。 如果相关要求比较严格,一般也可以在一定机制指导下,基于运维故障分析,用户需求搜集
1、还是比较折腾的,需要投入大量的资源研究、掌握并把各个开源组件糅合起来。2、如果要深入一点,像开源的一些缺陷和BUG等还需要投入很多额外资源修复。3、开源组件升级比较快,如何保证自有版本的升级,也比较复杂,做的不好
注册中心相对来说还算比较稳定,结合自己的实际选择就好,比如使用DUBBO的考虑ZK,选择SPRING CLOUD选择NACOS等,目前我理解下来EUREKA用得还是挺多的(虽然2.X闭源了),但是1.X还是比较稳定的。也有使用ETCD的,主要看是做企业级
我自己建议说把安全打入到关键环节中。比如在研发前,要考虑安全设计。编码时要考虑结合工具做代码检查。CICD时候要做第三方开源组件扫描,要有质量门禁。测试时自动化安全测试工具+人工渗透等结合。上线前安全检查,上线
建议是从软件交付的过程着手,在每个过程中思考是否需要规范、指引来保障,比如CI的时候会想到如果研发人员不按照规范些dockerfile会发生什么,有没必要对此做限制,有的话那就可以设计相应的规范指引,其他过程可以参考这个思
我觉得不是,DEVOPS是一种理念和方法的集合,工具链只是支撑DEVOPS落地的工具集合而已。DEVOPS关键的还是把敏态的软件研发方法在工具集合上运作起来,相对来说,我觉得怎么运作的难度比搭建工具的难度要大很多。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30