关于《小公司需要使用微服务架构吗？》的读后感

最近阅读了一篇文章《小公司需要使用微服务架构吗？》，这篇文章讨论了微服务架构的优缺点，以及微服务架构是否适合小公司。为了蹭一下热度，本文将结合两年半的练习经验，谈谈我对这篇文章的读后感。

New Bing 这样总结到：

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

这篇文章是关于小公司是否需要使用微服务架构的讨论，作者分析了使用微服务的四大门派，分别是跟风派，技术派，业务派和架构派。

跟风派是指那些盲目追随技术潮流，没有自己的判断和思考的人，他们认为微服务是一种万能的解决方案，可以提高开发效率，降低维护成本，提升系统性能和稳定性。

技术派是指那些喜欢尝试新技术，追求技术创新，不惧怕技术挑战的人，他们认为微服务是一种技术趋势，可以让他们学习更多的技术知识，提升自己的技术水平，增加自己的市场竞争力。

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

架构派是指那些有架构设计能力，能够从整体和局部的角度考虑系统的可靠性，可扩展性，可维护性，可测试性等方面的人，他们认为微服务是一种架构模式，可以让他们更好地构建和管理复杂的系统，实现更高的系统质量。

作者认为，小公司是否需要使用微服务架构，没有一个固定的答案，需要根据自己的实际情况和目标来决定，不要盲目地跟风或者拒绝。作者建议，小公司在使用微服务架构之前，要考虑以下几个方面 ：

• 微服务架构的优势和劣势，以及适用的场景和条件
• 微服务架构的实施成本和风险，以及应对的策略和措施
• 微服务架构的组织和管理方式，以及配套的技术和工具
• 微服务架构的演进路径和目标，以及评估和改进的方法和指标

作者最后总结，微服务架构不是一种银弹，也不是一种魔鬼，而是一种工具，需要根据自己的需求和能力来合理地使用。

软件工程本质上还是工程

工程可以被简单概括为在预期的时间内通过可控的成本达成预期的目标。 —— 正在掏下水道的良工

正如张工所说，工程问题本质就是时间、成本和目标之间进行平衡，最终以达成各方满意的结果。而为了实现这个一结果，软件工程中引入了各种理论、方法、工具和技术。它们或者是缩短时间、或者是控制成本、或者是改善目标，都是围绕这个核心目标展开的。

微服务本身作为工程实践中的一套理论和工具，也不能逃脱这个规律。为此，在决定是否采用微服务的时候，只需要考虑微服务是否能够帮助我们实现我们的目标，是否能够帮助我们缩短时间、控制成本、改善目标，就可以了。

例如，微服务架构的引入会由于服务数量的增加，而导致部署运维的难度增加，对应的就是增加了时间和成本。因此，在微服务架构应用时，就需要配到对应的运维工具以及有运维能力的人员，来缓解这个问题。使得整个工程的时间、成本和目标之间达到平衡。

没有充分了解就不具备评价问题的资格

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

常有人说我不懂制冷，但我有权评价空调。不过现在的场景是要造空调，因此，我需要了解空调的原理，才能够评价空调的设计是否合理。故而，如果要评价微服务架构是否合适，那么就需要了解微服务架构的原理，才能够评价微服务架构的设计是否合理。

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

1. 了解微服务架构的原理，包括微服务架构的优势和劣势，以及适用的场景和条件。
2. 掌握微服务架构的实施成本和风险，以及应对的策略和措施。
3. 明白微服务架构的组织和管理方式，以及配套的技术和工具。
4. 清楚公司的演进路径和目标，以及评估和改进的方法和指标。

我觉得一般来说，可以使用如下大致格式来界定评价方式：

针对问题：支付系统和物流系统的耦合性太高，导致系统的可扩展性和可维护性很差，需要解耦。
为何要解：公司业务发展迅速，需要接入更多的支付渠道和物流渠道，如果不解耦，系统将无法扩展。
解决方案：引入微服务架构，将支付系统和物流系统拆分为独立的服务。并成立两个团队，分别负责支付系统和物流系统的开发和运维。
引入成本：重构带来的过渡时间。额外的硬件成本，额外的人员成本。

矛盾的普遍性和特殊性

如果不研究矛盾的特殊性，就无从确定一事物不同于他事物的特殊的本质，就无从发现事物运动发展的特殊的原因，或特殊的根据，也就无从辨别事物，无从区分科学研究的领域。 —— 《矛盾的普遍性和特殊性》

微服务作为一套理论和工具，实质上是为了解决软件工程中存在的特殊矛盾而出现的。这个矛盾就是：软件工程中的复杂性和变化性。

而实际上，几乎任何引入到软件工程的理论、方法、工具和技术都是为了解决这一矛盾。因此也常有人说：软件工程唯一不变的就是变化本身。

故而，假如换做是别的理论或者工具，实际上讨论的方式都是相同的。例如：

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

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

微服务架构作为软件工程中使用到的一套理论和工具，本质上是为了解决软件工程中存在的特殊矛盾而出现的。为了能够评估引入的合理性，我们需要了解微服务架构的原理，包括微服务架构的优势和劣势，以及适用的场景和条件。这样的评价方式同样也适用于软件工程中使用到的其他理论、方法、工具和技术。