开源灵活，相对容易二次定制开发，无论是自己还是第三方，但开发周期可能比较长，项目见效慢。闭源功能齐全，可能会水土不服，过于笨重，涉及二次开发的内容需要原厂支持，自己和第三方很难做，但实施周期短，产品功能见效快。现在国内还有一种闭源的方式，就是提供一个平台，自己可以在这个平台...

微服务架构是近期比较流行的架构。要实现服务化，则首先要解决各个服务之间的通信问题。那么就会面临数据序列化、反序列化、连接管理、收发线程、超时处理等问题。如果自己实现一套这样的机制，不但重复劳动，性能和效率也难以保证。rpc框架的出现解决了这些问题，让调用者不必...

针对你的问题，分享一些我司做相关项目的经验。1.DevOps技术路线DevOps技术实现路线也有多种方式，最简单的是选择Jenkins。同时可以选择源码管理工具SVN或Git等，打包构建工具Maven或Gradle等，单元测试工具Junit等。和容器平台集成，实现持续集成和持续部署能力。项目初期可以使...

超融合平台相比于传统FC架构最直接而言是节省了san网络的相关费用，间接而言还节约了机柜空间和电力资源，对于很多租赁机柜的中小金融行业而言，这还是节约了不少成本。另外就是在应对快速扩容的资源需求时，超融合架构上线所需时间远远小于传统fc架构，可以说是插上线就可以使用，...

我们的资源监控用的是摩卡，应用监控用的是天旦，另外一家公司做的整体集成。运维一期项目主要是做到了资源的统一监控和管理，应用的监控；接着后面主要是进行CMDB、流程建设、自动化运维等；最后往智能化运维发展。...

笔者不敢妄言能否在多少年后被替代掉。毕竟很多系统目前都是基于传统的架构在运行的，从实际的角度出发，在传统架构没有出现非常无法解决的问题的时候，是不会有人有动力去使用超融合架构替代传统架构的，这里不仅仅是一个技术问题，更重要的是系统的稳定性的问题，就像现在很多大银...

就我所了解的，自动化运维项目有以下四条技术路线供大家参考1、基于开源工具自研基于社区活跃度高、口碑好、功能强大的开源自动化工具，进行二次开发，实现自身需求的完全定制化，该技术路线有两个理解层次，第一个层次只是开源工具的使用上，对该工具的所有模块的运用都非常娴熟，二...

如果公司技术实力雄厚可以玩开源，否则vmware是个很不错的选择，

正常分布式应该比较适合那种非结构化的文档，-大型运算应用我觉得更适合san架构，还有一个问题，就是企业自建私有云的时候分布式的存储可能会现在产品差距比较大可能自己维护下来要要相对来说难度大一些，...

各有各的好处。自建适合技术路线强调平台技术自主可控，创新重点放在基础平台上的用户；厂商提供方式适合的用户是希望借助厂商的技术力量确保底层平台的可靠性，而自己的技术路线更强调上层业务的发展和创新，强调治理能力、流程管理，而不是基础平台。个人认为，不以IT技术为自己核...