网站更新了,网上购物型网站,建立内部网站,石景山网站制作案例InfoQ#xff1a;您的论文“On the Definition of Microservice Bad Smells”涉及非常多的微服务不良做法#xff0c;但如果要用几个大类别来列举危害性比较大的微服务反模式#xff0c;您认为会是哪几类#xff1f;另外#xff0c;您能再大概分析说明下造成这个几个反模式…InfoQ您的论文“On the Definition of Microservice Bad Smells”涉及非常多的微服务不良做法但如果要用几个大类别来列举危害性比较大的微服务反模式您认为会是哪几类另外您能再大概分析说明下造成这个几个反模式的原因吗 Davide Taibi就我个人而言最坑的反模式存在于组织中而非技术之罪。技术上的反模式很容易修复(如循环依赖)而解决组织上的问题没那么简单。比如错误的开发团队分组将团队按水平功能划分而不是垂直划分(分成数据库团队、前端团队、后台团队)。 另一种组织结构问题可被称为“微服务贪心Microservice Greedy”指的是开发者对于任何可能的功能都创建新的微服务。他们都没有查看是否能重用代码甚至确认这个功能是不是已经存在就开始实现了。结果就导致微服务数量暴涨结构迅速退化 维护的复杂度和成本也随之激增。 InfoQ对于当前并不确定是否要选择云原生架构的企业您有哪些建议 Davide Taibi我给一些还不确定时候应用云原生架构的企业的建议是真实考量 你的需求你的组织结构以及公司开发者的经验。 如果有庞大数量的开发团队致力于不同的系统功能你可以考虑微服务。如果有些 功能你需要极限可扩展性那么你可以考虑无服务方法。其他的情形都需要准确地考量。 考虑到架构迁移的成本和影响雇佣有经验的咨询顾问是很明智的。他们会提供一 个“外来人”的视角在作出重要决定之前对企业和系统进行合理评估。 InfoQ最近谷歌开源了Service Weaver谷歌称此框架为模块化单体modular monolith称其能兼顾单体应用的开发速度以及微服务的可扩展性、安全性和容错性。但有人认为这就是一种“分布式单体”。您能解析对比分布式单体与模块化单体 之间的异同吗 Davide Taibi在我看来“分布式单体”只是对于“维护不了的分布式系统”的一种误导性的称呼。 我坚决同意一个设计优良具有模块化功能的单体系统维护起来可以很简单。但主要的问题不是软件本身而在于组织结构。过大的组织结构将导致团队缺少独立部署的能力。