原文: 7 Best Practices for Building Effective Microservices

微服务架构是软件开发领域的热门话题，这一话题如此值得关注是因为这种架构模式几乎解决了单体软件系统的所有重要痛点。快速扩容、减少停机时间、高可用性是微服务的主要附加值，对数据密集型应用来说尤其重要。无需赘言，下面我们来看看让微服务更高效、性能更强的一些最佳实践。

启用专用数据存储...

如果需要，每个微服务都应该拥有自己的专用数据库实例，与其他服务分开。在微服务架构的基础上建立后端，所有服务都使用一个数据库实例，并不意味着软件系统就是微服务，因为持久化层仍然是单体。稍微改进一点的办法是至少在表的上下文中将服务分开，即使所有表都在同一个数据库实例中，每个服务也有各自独立的表，但最好的办法是每个服务都有独立的数据库实例。

确定边界...

每个微服务的范围应基于单一责任原则，这意味着每个服务只有一个任务、一个职责。这里的主要问题是如何定义单一责任的细粒度，你需要避免因为范围太小而最终出现上百个微服务。这个问题的答案取决于特定 IT 项目的业务复杂性。

保持异步通信...

服务之间需要相互通信。如果业务复杂度很高，服务之间就会有很多相互依赖关系，而这些关系都是通过网络通信来处理的。在 SOAP 或 REST 等请求-响应通信模型中，通信都是同步的，意味着服务高度耦合。通过消息中间件、事件源或任何其他生产者-订阅者模式进行异步通信都会使服务高度解耦。

利用服务网格...

服务网格 (Service Mesh) 是通过代理实现服务间通信的基础架构层。这一专用服务层可实现许多功能，从而提高微服务的性能和效率。例如，安全连接、自动回复、对失败请求进行限流等。基本策略包括断路器、速率限制、流量转移。可以参考其他有关服务网格模式的文章^[1]，以加深理解。

分离 DevOps 活动...

每个微服务都应有专用的构建流水线，可以独立进行容器化部署。根据服务的具体需求，使用 Kubernetes 或 Red Hat Openshift 等容器协调服务，将使服务在需要扩展时更具弹性和性能。

使用中央日志和度量系统...

为了快速处理错误或进行根因分析，好的做法是集中记录和监控，所有服务都以相同格式提供日志和指标，从而有助于密切关注所有可能出现故障的服务。

根据服务而不是工具栈来组织团队...

受《敏捷宣言》启发，这一点在很大程度上是一个组织问题，而不是技术问题。根据服务或业务领域组建开发团队可以激励开发人员为其负责的服务进行全栈开发。根据技术栈来组建团队，比如一个团队负责前端，另一个团队负责后端等等，在当今是无效的，会造成技术垄断，使所有团队相互依赖。

你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！