作为一名开发人员，来谈谈微服务架构应用的优势

你可以自由地使用各种流行的技术

与使用大型、单体架构应用程序相关的一个大问题是，您被自己的技术所束缚。这可以分两个层面来说，第一，更老的或更有说服力的框架更有可能被选择。这意味着你不太可能使用太前沿的技术，而这正是许多开发者所看重的。第二是一旦选择了某种技术路线，通常需要付出很大的努力(通常是太大了)才能做出重大的改变。

我很高兴与microservices一起使用基于Spring和Grails的微服务，使用各自框架的最新版本。可以自由组合所使用的技术栈，这是很令人激动的事。

职责分离

SOA(面向服务的体系结构)的一个重要承诺是自包含的服务。在某种程度上，是黑匣子。对于微服务，这些边界更加严格。当事情作为单独的微服务运行时，职责自然就是分开的。它的结果是更清晰的抽象和代码，更易于使用。

体系结构更容易实施

在处理微服务时，体系结构通常非常明显。服务在不同的容器上运行，通常命名得很好。不需要查看文档或阅读大量的源代码。这使架构师和负责此级别设计的人能够清晰地实现他们的愿景。事实上，系统的每个部分都很小，并且很好地分离，这使得我们甚至可以快速地检查代码并确保没有任何可疑的事情发生。

显式地命名微服务还为开发人员和其他所有人提供了讨论系统不同组件的通用、明确的方式。

更改代码要容易得多

我发现，在一个项目中，实现微服务的代码要比一般的单体要容易得多。服务的重点和简洁是您最大的盟友。重构、重新运行测试和启动微服务通常比使用单体应用程序进行类似的工作要快得多，这也很有帮助。

我在这里没有提到的事实是，现代微服务框架(如Spring Boot或Grails)专注于减少不必要的配置和样板代码，而这些常常妨碍理解。我相信Spring Boot所做的是让更广泛的开发人员能够访问微服务，这多亏了这些努力。

测试可预期，更容易，更彻底

我已经看到了很少的具有自动化测试覆盖的组件，这些组件使每个人都对发布后的系统稳定性充满信心。几乎总是，需要一个大型的手动测试/qa团队。对于一个普通的企业来说，彻底自动化如此庞大而复杂的系统是非常困难的。

当微服务在其api中定义好的契约时，它们并不是那么可怕。有了良好的单元测试、彻底测试的端点和必要的集成测试，就更容易相信系统将按需要运行。

这种分离的另一个好处是，在一个服务中进行的代码更改不会影响其他服务中正在发生的事情。这大大减少了意外错误的几率。

总结

采用微服务有更多的好处，每个开发人员都会发现某些体系结构适合他们的其他原因，享受你的microservices 开发吧！