wangchang365

在可观测性方面，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关键的还是把敏态的软件研发方法在工具集合上运作起来，相对来说，我觉得怎么运作的难度比搭建工具的难度要大很多。