最近阅读了一篇文章《小公司需要使用微服务架构吗？》，这篇文章讨论了微服务架构的优缺点，以及微服务架构是否适合小公司。为了蹭一下热度，本文将结合两年半的练习经验，谈谈我对这篇文章的读后感。
原文摘要
New Bing 这样总结到：
你的问题是请帮你总结一下这篇文章主体的内容。我从网上搜索了一些相关的信息，发现这篇文章的主要内容是：
这篇文章是关于小公司是否需要使用微服务架构的讨论，作者分析了使用微服务的四大门派，分别是跟风派，技术派，业务派和架构派。
跟风派是指那些盲目追随技术潮流，没有自己的判断和思考的人，他们认为微服务是一种万能的解决方案，可以提高开发效率，降低维护成本，提升系统性能和稳定性。
技术派是指那些喜欢尝试新技术，追求技术创新，不惧怕技术挑战的人，他们认为微服务是一种技术趋势，可以让他们学习更多的技术知识，提升自己的技术水平，增加自己的市场竞争力。
业务派是指那些以业务需求为导向，根据业务场景和规模选择合适的技术方案的人，他们认为微服务是一种业务架构，可以让他们更好地解决业务问题，提供更好的用户体验，实现更快的业务迭代。
架构派是指那些有架构设计能力，能够从整体和局部的角度考虑系统的可靠性，可扩展性，可维护性，可测试性等方面的人，他们认为微服务是一种架构模式，可以让他们更好地构建和管理复杂的系统，实现更高的系统质量。
作者认为，小公司是否需要使用微服务架构，没有一个固定的答案，需要根据自己的实际情况和目标来决定，不要盲目地跟风或者拒绝。作者建议，小公司在使用微服务架构之前，要考虑以下几个方面 ：
- 微服务架构的优势和劣势，以及适用的场景和条件
- 微服务架构的实施成本和风险，以及应对的策略和措施
- 微服务架构的组织和管理方式，以及配套的技术和工具
- 微服务架构的演进路径和目标，以及评估和改进的方法和指标
作者最后总结，微服务架构不是一种银弹，也不是一种魔鬼，而是一种工具，需要根据自己的需求和能力来合理地使用。
欢迎关注作者的微信公众号“newbe技术专栏”，获取更多技术内容。
关注微信公众号“newbe技术专栏”
软件工程本质上还是工程
工程可以被简单概括为在预期的时间内通过可控的成本达成预期的目标。 —— 正在掏下水道的良工
正如张工所说，工程问题本质就是时间、成本和目标之间进行平衡，最终以达成各方满意的结果。而为了实现这个一结果，软件工程中引入了各种理论、方法、工具和技术。它们或者是缩短时间、或者是控制成本、或者是改善目标，都是围绕这个核心目标展开的。
微服务本身作为工程实践中的一套理论和工具，也不能逃脱这个规律。为此，在决定是否采用微服务的时候，只需要考虑微服务是否能够帮助我们实现我们的目标，是否能够帮助我们缩短时间、控制成本、改善目标，就可以了。
例如，微服务架构的引入会由于服务数量的增加，而导致部署运维的难度增加，对应的就是增加了时间和成本。因此，在微服务架构应用时，就需要配到对应的运维工具以及有运维能力的人员，来缓解这个问题。使得整个工程的时间、成本和目标之间达到平衡。
没有充分了解就不具备评价问题的资格
既然要做决定，你就应该有自信说出：没人比我更懂。
