微服务的八条建议

内部服务。“这些服务中的每一个都有自己的持续部署管道、独立的数据存储以及负责其开发和运营的各自团队，”坎贝尔说。

使用微服务时，各个组织可能会遇到许多挑战。这些挑战包括确定多个服务之间的正确边界，克服微服务环境中团队之间共享代码的困难，以及克服变更管理的复杂性，因为各团队都是独立发布代码。

转向微服务代表着一场大变革，各个组织需要做好应对这种重大转变的准备。

“向微服务的演变就像是从马到自行车，或从自行车到汽车的过程，”Solutions By Design II (SBD)公司项目副经理Jay Bercher说道，这是一家管理咨询和技术服务公司，与联邦机构合作，协助其转向基于微服务的IT工作方式。

“当我们经历演变的多个阶段时，我们会发现有更多的东西在变化，”Bercher说。“每个变化的东西都需要一定级别的维护，对这么多方面的支持和监督不仅使解决方案更加复杂，而且还增加了相关成本。因此，我们必须仔细审查我们的决定，以确保这些决定不仅是理想的技术决策，而且还具有成本效益。”

另一个挑战是安全性。“我们必须确定是否要在整个应用程序中实施单一验证解决方案，或者我们是否要对每个微服务都设置其自己的验证流程，”Bercher说。“这是一个必须根据具体情况做出的决定，并且是每个项目团队需要自己做出的决定。”

以下是一些建议的做法，以应对挑战并在微服务环境中顺利发展。

采用领域驱动设计

Bercher说，创建微服务是为了使服务松散耦合，并应用单一责任原则。

“尽管有各种开发方式和方法，但领域驱动设计和微服务似乎是非常合适的组合，”Bercher说。 SBD公司的团队使用领域驱动设计，这是一种构建应用程序的主题方法，可创建一种高效的开发模式，消除大多数团队的相互依赖性。

“在我们的工作中，领域与微服务的相关性基本上是一对一的，”Bercher说。“因此，每个开发团队都负责一个领域，同时也负责开发相应的微服务。这就建立了明确的责任划分，从而限制了并行开发工作中可能出现的冗余。”

建立代码库指南

坎贝尔说，在微服务环境下，团队之间共享代码要困难得多。

“不像在一个整体架构中，公共代码只是一个方法调用，而微服务架构的通用性必须分解到独立的服务中，或者代码必须打包到一个共享库中，”坎贝尔说。

使用这些库通常很慢，并且进行更改需要在库所有者和多个服务之间进行协调。“因此，对于公共库和上线产品的要求，各个组织应采用一套强有力的指导方针，这非常重要，”坎贝尔说。

不要在微服务之间共享数据库

“在构建我们的解耦合服务时，我们允许我们的开发团队构建自己的数据库，为我们的(后端系统)提供数据，这可限制对其他开发团队的依赖性，”Bercher说。

“我们的开发团队将他们书写的内容推送到后端，供其他人使用，然后我们的数据团队会管理这些信息，”Bercher说。“这延续了即插即用的概念。如果您需要更换某一服务，只需将其取出并插入新服务即可。这就像更换灯泡，只是稍微复杂一点。”

由于微服务在设计上是模块化的，因此开发过程主要是即插即用，从而可以非常轻松地解决可能出现的任何问题。

“因为代码不会在整个平台上传播，我们可以快速将问题隔离到一个特定的源，然后在微服务中对其跟踪，”Bercher说。“通过允许对每个微服务进行零碎的更新和升级，可以轻松更新应用程序。你能想象一次升级一个系统而不进行大规模替换吗?仅这一概念就彻底改变了系统开发。”

SBD公司在美国各地设有开发团队，可以增强微服务的优势

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!