阅读时间： 3 分钟
技术部门对微服务都很兴奋。它能够将庞大的应用程序分解成缩小的、独立管理的和更新的组件，使其成为一个可供选择的方案。微服务的好处故事一方面建立了兴奋点，另一方面，它的设计也不是那么简单的。
微服务在改变机构的应用准则方面有着巨大的潜力。微服务应用允许你在各个小组之间分配工作，这样每个小组都可以在特定的应用部分工作，而不会给其他小组带来额外的工作量。
让我们来看看如何设计微服务架构？
为每个微服务建立一个独特的数据存储器
同样的后台数据存储不应该在整个微服务中使用。你希望每个微服务的组都能选择适合该服务的数据库。此外，在唯一的数据存储下，由不同团队编写的微服务对数据库结构进行分割是非常安静的，可能是为了减少工作的重复性。你会达到这样的情景：当一个小组修改数据库的形成时，其他同样使用同一数据库的平台也必须改变。
分离文件会使数据管理复杂化，因为存储系统可能变得不稳定或不同步，而远程密钥可能会发生不可预知的变化。你可能需要设计一个工具，通过在后台运作来实现主数据管理（MDM），以识别和修复不正常的情况。
维护代码
让所有的代码处于相关的稳定性和成熟度的水平。用更简单的话说，如果你需要重写或增加已安装的微服务中的一些代码，这些代码运行良好，那么最好的方法是为修改后的代码建立一个新的微服务，保留当时的微服务在其位置。这样，你可以设置和测试运行新的代码，直到它没有错误和高效，而不会出现性能下降，也不会有现行微服务失败的风险。一旦新的微服务和原来的一样牢固，如果它们一起执行一个单一的功能，你就可以把它们重新组合起来。
为每个微服务创建一个不同的构建****微服务的实现
为每个微服务创建一个独特的构建，其方式是以适合它的审查级别从源头拉入模块记录。它偶尔会把你带到这样的状态：几个微服务拿出一组相关的文件，但处于不同的修订级别。它可能会使通过撤销旧文件的版本来清理代码库成为一种挑战，但这是对你设计新的微服务时增加新文件的无压力的更好交换。
在容器中设置
安装一切是必不可少的，因为你只需要一个工具来安装整个东西。因为只要微服务在一个容器中，工具就知道如何安装它。容器是什么并不重要。也就是说，Docker似乎已经变成了容器的标杆。
将服务器视为无状态-
考虑服务器，特别是运行面向客户的代码的服务器，作为可交换的小组成员。他们都完成同样的任务，所以没有必要为他们的独立而烦恼。你唯一担心的是它们的数量是否能产生你所需要的工作数量，以及使用自动扩展来改变数字的涨跌情况。如果一个停止了，它就会被一个自动取代。
让我们用一个虚构的电子商务应用的例子来理解这个结构
让我们设想一下，你正在开发一个电子商务应用程序，它将接受来自客户的订单，确认库存和现有的信用，并发送它们。该应用程序涉及各种组件，它们执行用户界面，还有一些后台服务，用于保持库存、检查信用和发送订单。该应用程序包括一组服务。
这就是关于设计微服务架构的基础知识的简介。当你选择像Knoldus Inc.这样有经验的公司时，这个过程只会变得更容易和更有效。因此，去抛弃自己动手的复杂性，聘请专业人士来照顾你的组织的微服务架构。
也发表在Medium上。
