【SFA译】：让你的团队为微服务做准备——第2部分
让你的团队为微服务做准备——第2部分
原文链接：https://dzone.com/articles/getting-your-team-ready-for-microservices-part-2
作者：Sowmya Halappa、RJ Williams
译者：Darren Luo
通过了解和实现微服务架构，了解更多有关分解复杂性为团队带来的好处。
非复杂微服务架构的好处
为了确定微服务架构是否适合你的产品开发，我们需要知道它提供了什么。这不应该是一个单方面的决定，而应该和团队达成共识，因为最终是团队开发产品，因此团队应该参与这个决策过程。不管结果如何，团队应该拥有决定并采取相应行动。
在暴露整体架构导致的问题给你的团队之后，如我的文章“让你的团队为微服务做准备：第1部分——为什么使用整体架构开发复杂应用程序不是一个好主意？”，接下来的任务是揭示使用微服务架构的好处和缺点。在本文，我们来看看微服务架构提供的优势。你可能不能利用微服务提供的所有好处，但这些优势可用于你的讨论，以提出问题并作出明智的决定。
什么是微服务驱动的架构？
这是一种支持使用低耦合的服务构建应用程序的架构，具有清晰的接口/API 以及服务间通过 HTTP、消息传递等通信。这些服务中的每一个都是独立的，可以使用不同的编程语言编写，并且还可能使用不同的数据库。这和整体应用程序不同，整体应用程序作为单个单元构建和部署，通常只用一种编程语言、一个数据库，并运行在一个平台上。必须要更改才能在云平台上运行相同的整体应用程序。
拥抱微服务的另一个动机是它提供的可拓展能力。这使得微服务比整体应用相同更受欢迎，随着软件的模块/代码/团队的的增加，整体应用扩展困难。
微服务的另一个主要优点是可移植性。回顾一下，这是 Java 变成一个非常流行的编程语言的主要原因，当一个 Java 程序在一个环境中编写时，它（字节码）可以被移植并在任何提供 JRE 的环境中使用。同样的，微服务应该是可移植的，可以在任何环境中部署和运行——物理机、云、容器等。
总的来说，微服务架构显示了应用程序服务的潜力，可根据需要独立部署和扩展。
打破复杂性！
这是使用微服务架构最明显的好处。这种架构为我们提供了一种打破在多个服务器作为独立单元运行的整体代码的复杂特性的方法。微服务架构强制我们思考并开发集成顺畅的松耦合服务。这些组件应该在独立的流程中运行。每个服务都包含业务功能，并包含完整提供此功能的代码。这意味着要包含所有的用户界面/北向接口、业务、数据库和其他需要的层。团队必须是跨职能的，并能自行提供端到端服务。这将导致更多业务驱动的决策和团队/组织内不同的工作方式，围绕服务和业务能力。
更快的产品开发生命周期
拥抱微服务架构具有积极的副作用：开发和测试变得更容易，如果部署方案足够简单，产品开发的整个生命周期将会缩短。设计人员可以在不同的代码库上独立工作，而不是相互踩着对方的脚，这需要大量的协调工作。
当然，因为这种独立性存在着天生的复杂性，因为这使得服务自主的使用其手段进行内部和外部通信。各种服务间的通信必须防止故障且高效的。值得庆幸的，在编写服务方面有一些指导方针和模式可以帮助我们解决这些问题，其中一个是“让你发送的内容保持保守，让你接收的内容保持开放”。关于使用API网关和其他特性有一些最佳实践，我们将在接下来的几篇文章中介绍这些特性，我们可以利用它们。
易于测试
当应用程序基于微服务架构时，你不需要为测试环境启动整个应用程序堆栈，只需要让相关的服务运作就足够了。
使用微服务，我们不必遵循命令使用就得测试策略和旧的测试规则。微服务肯定会创造现代思维的工具的使用和理论需要和应用。这进一步使开发团队完全自主的选择测试范围、测试类型，并相应的为正在开发的服务设置测试意愿。在选择与服务相关的正确的功能和非功能方面存在自主权。自由带来责任——合理的假设团队完整的测试服务并发布负责的验证或 QA 验证团队做一个系统级测试仅限于接口通信或在系统级而不是服务级测试非功能性方面。应该大大减少对外部测试/验证的依赖。
事实上，团队可以决定什么使最适合在生产前测试的，哪些适合生产后进行测试。
由于微服务架构提供的模块化，软件测试变得更容易，因此在产品到达客户之前可以编写和测试更好和有价值的测试。
更少的缺陷/易于故障排除
缺陷减少的一个原因使由于模块化和良好的测试覆盖他们的结果，编写明确的测试和有效测试端到端的能力。因此，更少有缺陷会被客户发现。每个微服务都侧重于单一功能，这使得它很容易找到服务出错的位置并诊断问题。可以证明的事实是，当我们加入新成员时，上手的时间减少了，并且他们能很快的调试应用程序。
另一方面，如果代码不易调试，则团队有责任确保实现足够的检测和日志记录机制，以启用正确的监控和故障排除。
这使得团队有机会思考他们如何实现服务：是独立的还是忽略了 SOLID 的单一责任原则或其他任何清洁代码的原则。再次强调，团队的责任是让代码变得简单或难以出现故障。但与调试整体应用程序相比，这种复杂性要小得多。
不再集中治理
使用微服务架构，设计人员编码的服务可以包含在他们的开发环境中。因此，这再次导致集中式环境的服务的协调为 0 或更少。假设同意公开 API，每个服务能用设计环境提供的资源进行测试。
我们不再需要使用单一语言或框架来开发不同的的服务，而是针对正确的服务使用正确的技术。我们可以选择最适合服务的数据库，而不是坚持集中式数据库。这可以是关系型数据库，面向对象数据库，甚至是 NoSQL 数据库。服务可以权衡 CAP（CAP 理论）的某个方面选择数据库并做出合适的决策，而无需选择由整体应用程序确定的单一数据管理方案。此决策可以基于数据管理解决方案主要计划被用于的内容——是持久性、检索、性能还是更新数据？
我们甚至可以做出使用的编程语言这样的决策，每个服务可以选择最适合服务的语言。这主要因为并非所有问题都可以用单一编程语言解决。升级到最新版本的 3PP 或改变使用的一个工具使你的服务完全隔离。
这确实保证了团队的自主性，他们不需要遵循某些人定义的 PMD 规则、检查样式，但可以满足他们的需求。团队可以定义他们适合自己的工作方式，而无需等待多数人的共识。这通常可以给开发团队通过探索不同的技术提升他们水平的机会，并为团队内的健康谈论提供空间。记住，最后使开发团队拥有代码！
总之，打破复杂性的好处有
易于软件开发
易于增加团队/团队成员
更少的缺陷和更多的软件开发时间
易于测试
易于排查故障
减少维护费用
容易理解代码——更少的上手时间
团队自主性
团队授权
能选择最适合的技术/3PP
能选择合适的编程语言
能选择合适的数据管理解决方案
团队内协调更少或为 0
关注团队的工作方式而不是组织的工作方式
当然，这不仅仅使微服务架构所承诺的轻松。还有其他的好处，我将在接下来的几篇文章中介绍。