微服务能够为混合云或多云部署带来大量的好处，但是它们也能够带来与网络、安全性等相关的新挑战。
大多数IT企业已经开始认识到在开发和部署中实施软件组件化的好处。在云中，组件化带来了重要的优势，例如增加弹性和支持横向扩展。
微服务（即通常在应用程序中共享的小型功能组件）能够显著地放大这些优势。但是，首先用户必须正确地规划、开发和部署微服务。
了解如何让微服务起作用
如需开始规划微服务，IT团队需要了解微服务与以服务为导向架构中应用程序组件或元素的不同之处。微服务不是完整的应用组件；它们是在应用中作为服务专为共享而设计的——这意味着多个应用能够在同一时间内调用微服务的单个实例。微服务也是专为使用类似于网络RESTful接口而设计的。
如果微服务不符合上述定义，那么它们可能不会提供很多好处的。当微服务能够符合上述特点时，用户需要在混合云或多个云部署中维护每一个微服务。
微服务对多云网络的影响
因为微服务是小块的功能组件，它们可以将应用程序分解成为对外部服务的很多个连续请求。这个用于访问服务的网络有可能引入传输延迟和其他网络性能问题。至关重要的是，链接微服务和使用它们提供服务质量（QoS）的应用的网络连接需要支持用户体验。在用户部署微服务之前，应跨用户的混合云或多云环境测试所有负载变化下的微服务运行性能。如果用户的服务质量低于可接受水平，那么可变更网络连接以矫正之。另外，用户可以设计自己的应用部署过程以便于服务不会移动到用户网络中的盲点。
混合云和多云应用中的网络性能问题通常都与数据流量流经多云、或云和数据中心以及边界点的方式相关。可以与用户的云供应商进行沟通，让用户的VPN供应商和数据中心团队协力优化网络连接性。应特别谨慎处理多云应用，因为很多公共云供应商并不与其他供应商直接相连；他们会希望连接通过用户的VPN或数据中心网络。如果在一个云中的一个应用使用了另一个云中的一个微服务，那么就存在着一个长传输延迟的潜在可能。如果用户不能降低延迟时间，那么就应尽量避免跨云供应商网络的微服务访问。用户可能需要在每一个云环境中都部署一个服务副本，从而避免这样的网络性能问题。
多个应用程序访问微服务还需要专门的优化网络。访问微服务的最简单方法就是假定拥有一个连接用户所有云和数据中心的专用网络。通过使用这种方法，用户可以在任何位置部署微服务，而应用可以使用标准IP机制——URL和域名服务（DNS）或其他服务目录方法，来让应用程序访问它们。
当微服务在不同云供应商之间或在云供应商与数据中心之间迁移时，还会带来另一个挑战。通常情况下，这种迁移需要改变IP地址，这意味着微服务迁移后必须将服务逻辑名称关联不同地址。应确保用户有用于更换故障组件的工具和措施，从而对DNS或服务目录项做出必要的修改，以便用户的应用程序能够在微服务的新地址找到新服务。
安全地部署微服务
多个应用经常共享一个单一的微服务，这一事实带来了混合云和多云环境中的另两个挑战：安全性和合规性，以及状态和无状态行为。
由于应用在任何时候都在共享功能，所以具有严格合规性需求的应用程序就存在着违规风险。这是因为共享服务可能会为外人留下一个进入的窗口。由于迁移微服务或在负载下复制微服务需要相当开放的寻址方法，所以用户需要确保每一个微服务及其访问的安全性。避免微服务混合要求安全性和合规性监控的功能与其他开放给更大社区的功能——让它们成为两个不同的微服务。
探索状态和无状态问题
状态与无状态问题是很复杂的，即便对于软件架构师和开发人员来说亦是如此。应用程序通常支持包括多个步骤或状态的交易型活动。例如，假设我们有一个被称为“两个数相加”的服务。如果我们在一个请求中提出第一个数，在另一个请求中提出第二个数，而其他用户可能会无意中在我们的两个数之间引入他们自己的数字，那么我们就会得到错误的答案。
如果微服务无法在向它发出的请求之间保存数据，那么如有需要可令请求无状态或者确保他们能够以某种方式传输状态。在我们的例子中，提供两个待相加的数字就可省去多次请求以及消除状态行为风险。此外，还可以让请求包含一个微服务能够通过后端数据库与状态关联的用户ID。当提出我们的第一个数时，微服务将在数据库中记录下这个数。然后，当提出第二个数时，微服务就能够将两个数相加并返回结果。
对于多功能性、敏捷性和灵活性总是有一个物有所值的价格的，而在混合云和多云中使用微服务则代表着我们研究领先优势的这三项特点。仔细规划、尽量降低价格并部署可轻松扩展至复杂云未来的微服务。
本文转自d1net（转载）