关于c#:关于小公司需要使用微服务架构吗的读后感

最近浏览了一篇文章《小公司须要应用微服务架构吗？》，这篇文章探讨了微服务架构的优缺点，以及微服务架构是否适宜小公司。为了蹭一下热度，本文将联合两年半的练习教训，谈谈我对这篇文章的读后感。

原文摘要

New Bing 这样总结到：

你的问题是请帮你总结一下这篇文章主体的内容。我从网上搜寻了一些相干的信息，发现这篇文章的次要内容是：

这篇文章是对于小公司是否须要应用微服务架构的探讨，作者剖析了应用微服务的四大门派，别离是跟风派，技术派，业务派和架构派。

跟风派是指那些自觉追寻技术潮流，没有本人的判断和思考的人，他们认为微服务是一种万能的解决方案，能够进步开发效率，升高保护老本，晋升零碎性能和稳定性。

技术派是指那些喜爱尝试新技术，谋求技术创新，不害怕技术挑战的人，他们认为微服务是一种技术趋势，能够让他们学习更多的技术常识，晋升本人的技术水平，减少本人的市场竞争力。

业务派是指那些以业务需要为导向，依据业务场景和规模抉择适合的技术计划的人，他们认为微服务是一种业务架构，能够让他们更好地解决业务问题，提供更好的用户体验，实现更快的业务迭代。

架构派是指那些有架构设计能力，可能从整体和部分的角度思考零碎的可靠性，可扩展性，可维护性，可测试性等方面的人，他们认为微服务是一种架构模式，能够让他们更好地构建和治理简单的零碎，实现更高的零碎品质。

作者认为，小公司是否须要应用微服务架构，没有一个固定的答案，须要依据本人的理论状况和指标来决定，不要自觉地跟风或者回绝。作者倡议，小公司在应用微服务架构之前，要思考以下几个方面：

• 微服务架构的劣势和劣势，以及实用的场景和条件
• 微服务架构的施行老本和危险，以及应答的策略和措施
• 微服务架构的组织和治理形式，以及配套的技术和工具
• 微服务架构的演进门路和指标，以及评估和改良的办法和指标

作者最初总结，微服务架构不是一种银弹，也不是一种魔鬼，而是一种工具，须要依据本人的需要和能力来正当地应用。

欢送关注作者的微信公众号“newbe 技术专栏”，获取更多技术内容。

软件工程实质上还是工程

工程能够被简略概括为在预期的工夫内通过可控的老本达成预期的指标。—— 正在掏下水道的良工

正如张工所说，工程问题实质就是工夫、老本和指标之间进行均衡，最终以达成各方称心的后果。而为了实现这个一后果，软件工程中引入了各种实践、办法、工具和技术。它们或者是缩短工夫、或者是管制老本、或者是改善指标，都是围绕这个外围指标开展的。

微服务自身作为工程实际中的一套实践和工具，也不能逃脱这个法则。为此，在决定是否采纳微服务的时候，只须要思考微服务是否可能帮忙咱们实现咱们的指标，是否可能帮忙咱们缩短工夫、管制老本、改善指标，就能够了。

例如，微服务架构的引入会因为服务数量的减少，而导致部署运维的难度减少，对应的就是减少了工夫和老本。因而，在微服务架构利用时，就须要配到对应的运维工具以及有运维能力的人员，来缓解这个问题。使得整个工程的工夫、老本和指标之间达到均衡。

没有充沛理解就不具备评估问题的资格

既然要做决定，你就应该有自信说出：没人比我更懂。🤗 —— 和领导一起上厕所的汪总

常有人说我不懂制冷，但我有权评估空调。不过当初的场景是要造空调，因而，我须要理解空调的原理，才可能评估空调的设计是否正当。故而，如果要评估微服务架构是否适合，那么就须要理解微服务架构的原理，才可能评估微服务架构的设计是否正当。

作为练习时长两年半的工程师，我能够很有自信的说出：没人比我更不懂微服务架构了。所以我也不具备评估微服务架构是否适合的资格。不过我感觉如果有那一天可能决策是否采纳微服务架构，那么我应该做过上面这些事件：

1. 理解微服务架构的原理，包含微服务架构的劣势和劣势，以及实用的场景和条件。
2. 把握微服务架构的施行老本和危险，以及应答的策略和措施。
3. 明确微服务架构的组织和治理形式，以及配套的技术和工具。
4. 分明公司的演进门路和指标，以及评估和改良的办法和指标。

我感觉一般来说，能够应用如下大抵格局来界定评估形式：

 针对问题：领取零碎和物流零碎的耦合性太高，导致系统的可扩展性和可维护性很差，须要解耦。为何要解：公司业务倒退迅速，须要接入更多的领取渠道和物流渠道，如果不解耦，零碎将无奈扩大。解决方案：引入微服务架构，将领取零碎和物流零碎拆分为独立的服务。并成立两个团队，别离负责领取零碎和物流零碎的开发和运维。引入老本：重构带来的过渡工夫。额定的硬件老本，额定的人员老本。

矛盾的普遍性和特殊性

如果不钻研矛盾的特殊性，就无从确定一事物不同于他事物的非凡的实质，就无从发现事物静止倒退的非凡的起因，或非凡的依据，也就无从分别事物，无从辨别科学研究的畛域。——《矛盾的普遍性和特殊性》

微服务作为一套实践和工具，本质上是为了解决软件工程中存在的非凡矛盾而呈现的。这个矛盾就是：软件工程中的复杂性和变动性。

而实际上，简直任何引入到软件工程的实践、办法、工具和技术都是为了解决这一矛盾。因而也常有人说：软件工程惟一不变的就是变动自身。

故而，如果换做是别的实践或者工具，实际上探讨的形式都是雷同的。例如：

• 是否应该引入容器化
• 是否应该采纳某种编程语言
• 是否应该划分一个新的部门

总结

原文作者内容清晰，表述残缺，逻辑谨严，值得学习。

微服务架构作为软件工程中应用到的一套实践和工具，实质上是为了解决软件工程中存在的非凡矛盾而呈现的。为了可能评估引入的合理性，咱们须要理解微服务架构的原理，包含微服务架构的劣势和劣势，以及实用的场景和条件。这样的评估形式同样也实用于软件工程中应用到的其余实践、办法、工具和技术。

参考

• 小公司须要应用微服务架构吗？¹

感谢您的浏览，如果您感觉本文有用，快点击下方点赞按钮👍，让更多的人看到本文。

欢送关注作者的微信公众号“newbe 技术专栏”，获取更多技术内容。

• 本文作者：newbe36524
• 本文链接：https://www.newbe.pro/Others/0x021-after-reading-Do-Small-Companies-Need-to-Use-Microservices-Architecture/
• 版权申明：本博客所有文章除特地申明外，均采纳 BY-NC-SA 许可协定。转载请注明出处！