微服务 微应用
微服务拒绝
客户多次说过; 他们无法想象他们的组织使用微服务。 我感到惊讶,因为我知道那些人已经在使用微服务的许多原理。
我可以理解,他们觉得没有必要加入对微服务的炒作,但事实是,无论您是否喜欢,您都可能会使用微服务倡导的一些最佳实践。
拒绝的阶段
- 一切似乎都在大肆宣传,我们不赞成这样做。
- 也许不是所有的炒作,但这真的意味着什么。
- 听起来都很熟悉。
- 听起来好像我们已经在做。
正式或非正式地,您很可能已经遵循了一些最佳实践。
采用最佳做法。
也许您不喜欢微服务这个名字,也许与微服务相关联的所有事物都不适合您的团队和项目。 相反,让我们考虑如何将要达到的目标正式化,并找到更清晰的采用最佳实践的途径。
为什么要这么做呢?
在较大的团队中,关于如何进行可能存在一些分歧。 人们可能会对坏的事情有强烈的感觉,或者对自己拥有的东西感到沮丧,而诱惑就是只丢弃大部分自己的东西或丢弃一切。
这样做的问题是您冒着淘汰旧的已知问题并放入更多新的未知问题的风险。 您需要进行更改,可能有选择地进行根本性更改,这些更改对于您的团队而言是可管理和可实现的。
通过规范化您正在谈论的内容,甚至使用流行语,您也可以更清楚地陈述您要实现的目标以及原因。 它为您提供了一种交流您的想法的通用语言。 它可以让您更好地了解自己今天所处的位置以及需要成为的位置。
最佳做法记分卡。
使用记分卡,您可以快速了解您的当前位置,快速获胜的位置以及中期所需的位置。 问题的很大一部分; 我们今天在哪里,只是在重新命名您已经拥有的产品。 这篇评论可以使您以某种方式发现自己并没有想象中那么糟糕,而与此同时形成鲜明对比的是最有机会改善的领域。
初步步骤
我建议的初始步骤是
- 重塑您的财产; 您已经有了一些最佳做法。
- 快速获胜; 低风险的变化可以帮助您改善职位。
- 中期改进; 在接下来的六个月中您需要实现什么。
一个例子。
这是我为60多个开发商的公司的高级经理汇总的计分卡。 在一个小时的时间内,我们从不考虑微服务,到确信这是增强其解决方案的途径。
今天 | 快速获胜 | 6个月 | |
---|---|---|---|
简单的基于组件的设计。 | ★★ | ★★☆ | ★★☆ |
由JVM和Machine分发 | ★★ | ★★ | ★★☆ |
服务发现 | ★★ | ★☆ | ★★ |
抵抗失败的能力 | ★☆ | ★☆ | ★★ |
运输不可知 | ★★ | ★☆ | ★★ |
异步消息传递。 | ★☆ | ★★ | ★★ |
自动化的动态服务部署。 | ★☆ | ★★ | ★★☆ |
服务本地私有数据集。 | ☆ | ★★ | ★★ |
透明的消息传递。 | ☆ | ★★ | ★★☆ |
Lambda建筑 | ★★ | ★★ | ★★★ |
这并不是详尽的清单。 这是我们在第一个小时内进行的审查。 |
后两个领域被认为是最重要的改进领域,因为它们都是低风险的,但很有可能揭示出他们所遇到的一些反复出现的问题的原因。
尤其是,性能和稳定性问题需要有关系统运行状况的质量,详细信息,因此,您可以从有见识的角度了解需要进行哪些更改以修复它。
结论
无论您是喜欢还是讨厌微服务,很可能您正在使用某些最佳实践,并且对微服务中使用的最佳实践进行回顾可能会有助于您了解如何改善自己的服务。
翻译自: https://www.javacodegeeks.com/2016/05/microservices-applying-group-best-practices.html
微服务 微应用