随着互联网的不断发展，微服务架构在软件开发领域中有了一席之地，下面我们就一起来了解一下，关于微服务架构的注意事项都有哪些。
微服务边界
使用微服务开发新系统的核心优势之一是该体系结构允许开发人员独立构建和修改各个组件，但在大限度地减少每个API之间的回调数量方面可能会出现问题。根据SparkPost工程副总裁ChrisMcFadden所说，解决方案是应用适当的服务边界。
关于边界，与有时难以理解和抽象的领域驱动设计(DDD，一种微服务框架)形成鲜明对比，本文重点介绍了和我们行业的一些CTO一同建立的明确定义的微服务边界的实用原则。
避免主观的“规则”
如果您阅读了足够多的关于设计和创建微服务的建议，您一定会遇到下面的一些“规则”。尽管将它们用作创建微服务的指南很有吸引力，但加入这些主观规则并不是思考确定微服务的边界的原则性方式。
“微服务应该有X行代码”
让我们直说：微服务中有多少行代码没有限制。微服务不会因为您写了几行额外的代码而突然变成一个独石应用。关键是要确保服务中的代码具有很高的内聚性(稍后将对此进行更多介绍)。
“将每个功能转换为微服务”
如果函数基于三个输入值计算某些内容并返回结果，它是否是微服务的理想候选项?它是否应该是单独可部署应用程序?这确实取决于该函数是什么以及它是如何服务于整个系统。将每个函数转换为微服务在您的情景中可能根本没有意义。
其他主观规则包括不考虑整个情景的规则，例如团队的经验、DevOps能力、服务正在执行的操作以及数据的可用性需求。