微服务需要考虑的几点内容, :)
团队规模
团队成员能否围坐在一张桌边？
Yes！ -- 你可能不需要微服务
好文档和好设计可以轻易解决部署等运维操作中遇到的挑战。而微服务要解决的问题你还没有遇到。
No！ -- 微服务应该能帮到你！
团队大到一定规模了、或者多个团队同时工作，仅仅单靠好的设计已经不能保证组件之间有着清晰的边界。这时将组件间的边界强制变为各独立服务间的边界会很有帮助。
状态
你的系统主要部分是否是无状态的？
Yes！ -- 考虑无服务器架构（serverless）吧！
如果都是无状态的，你可能可以直接跳过微服务，直接使用无服务器架构——至少对你的部分系统使用。
No！ -- 微服务将带来额外的复杂性
并不是说不要使用微服务，而是要意识到它们对于实现管理来说并不重要，尤其是当系统随着时间推移而不断变化的时候。
用户
你的设计用于单个app或者服务吗？
Yes！ -- 小心！可能会有模糊的域名
如果你的设计只服务于单一消费方（Consumer），你将会发现每次新增特性时都要同时更新许多个服务。微服务可能有效，但在设计域名时要千万小心。
No！-- 微服务非常有价值
如果服务有多个不同的消费方，微服务就变得非常值得尝试，它将允许你给新增的消费方快速带来新特性。
依赖
服务是否有整体依赖？
Yes！ -- 性能是一个问题
这种场景下性能依赖于统一的被依赖方，因此独立的/可扩展的服务没什么好处。设计服务边界也是一个难题
No！-- 微服务很有价值
如果不受限于一个整体的下游，你将可以实现微服务有效扩展所需的高度独立性。
专业知识
你是否有 容器、编排、devops 方面的专家？
Yes！ -- 微服务是有价值的
如果团队中有专家，微服务是值得一用的。去处理它的复杂性并获得它的好处吧！
No！ -- 请先考虑实验
如果没有专家支持，或者正在devops中挣扎，直接上微服务将是一个巨大的挑战。更现实的选择是考虑一个小而简单的服务作为突破来验证想法。首先在项目中学习微服务，而不是直面现实任务中的困难。
来源：oschina
链接：https://my.oschina.net/u/140355/blog/1617217