对于刚开始考虑使用微服务来开发自己业务或者想学习微服务架构的微服务领域的新手程序猿来说，首先，我们要快速了解微服务如何在日后的工作中为您的开发工作带来的好处。
有国外统计数据表示：微服务(或微服务架)的普及正在迅速增长。预计未来五年，全球云微服务市场将增长到18亿美元，2018年至2023年间的增长率为22.4％。
微服务架构因其对数据库和应用程序开发的内在优优势而越来越受欢迎。。微服务体系结构采用模块化方法，将大型软件项目分解为更小，更独立，更易于管理的部分。因此，它为IT团队及其企业提供了许多关键优势。以下是微服务的七大优势。
1.专注、富有成效的团队
微服务背后的核心原理是将大型应用程序细分为多个小的独立功能。每个功能都由一个小型，高度专注的团队提供支持，该团队负责其服务，并确保他们为该服务选择适当的技术，流程和工具。负责一项专门的职能可确保团队准确了解他们关注的内容及其可交付的时间表。单一关注有助于团队实现零增长并提高工作效率。
2.更快和轻松的部署
每个微服务根据其自己的进程运行，并且通常管理其自己的数据库。这样一来，IT团队就可以与其他组织就其他应用程序的进度进行协调，或者等待部署代码，直到整个应用程序或更新就绪为止。每个微服务团队都可以设置和管理其部署计划，以更快地完成项目并提高应用程序部署的整体速度。
3.错误和故障隔离
当微服务架构隔离功能时，同时它也隔离错误。一个微服务中的问题不会关闭整个应用程序，它将被包含在一个区域中，而其他微服务将继续运行。这不仅可以提高正常运行时间，而且可以更轻松地找出问题的根源并加以解决。
4.安全监控
隔离错误的相同结构隔离了安全问题。即使应用程序的一部分受到破坏或遇到安全问题，它也不会影响应用程序的其他区域。这种隔离使得在保持应用程序正常运行的同时，更容易识别问题并快速解决它们。
5.兼容CI / CD和敏捷
微服务架构与软件行业中最有效的流程兼容，包括CI，CD，敏捷和容器方法。团队可以选择最适合自己需求的流程，将微服务集成到他们的开发方法中，并使用他们喜欢的任何工具，例如Docker和Kubernetes。
6.持续的质量改进
通过使用专注的模块，微服务体系结构提高了应用程序系统的整体质量。团队专注于小型，定义明确的功能，使他们能够创建高质量的代码段。这不仅对代码的可靠性产生积极影响，还使在管理代码库中的问题变得更加容易，同时实现了第三方服务的可伸缩性和可重用性。
7.可扩展性
可以轻松地从应用程序中提取独立功能，以在其他应用程序中重用和重新利用它们，并提高可伸缩性。各个开发团队还可以实施和部署他们的代码，而无需花费较大的IT团队或部门的时间。这使大型组织更容易使用微服务架构来减少内部政治和其他可能延迟部署的问题。
8.微服务帮助团队更加高效
微服务架构的最大优势在于创建小型，专注的团队，这些团队可以更快地以更高的质量开发独立的功能。它与主要的开发方法（例如， 持续集成 和交付）以及DevOps一起使用，以改善流程，从而使整个企业的IT团队更加有效。
以上说了微服务会带来这么多好处，那么为什么现实中有些公司会考虑放弃微服务这种方式，实际问题实际问题，未来的趋势，微服务化这种编程模式不可逆，但我们也要了解微服务会存在哪些缺点，导致目前微服务应用不了，比如：
微服务架构带来过多的运维操作, 可能需要团队具备一定的 DevOps 技巧;
分布式系统可能复杂难以管理，因为分布部署跟踪问题难。当服务数量增加，管理复杂性增加。但，这些问题往往会发展出更多的工具和技术来完善。
所以，在实施微服务同时，要考虑自己的公司或团队具不具备一定的先决条件：
基础的运维能力（如监控、快速配置、快速部署）需提前构建，否则就会陷入较被动的局面。推荐采用CI/CI改进基础设施及运维的实践，通过自动化运维使得可以快速安全的响应和处理微服务对服务部署的要求，通过容器技术保证服务环境之间拥有更高的一致性，降低“在我的环境工作，而你的环境不工作”的可能，也是为后续的发布策略和运维提供更好的支撑。
微服务迁移的最佳实践
当被问及开发人员在迁移到微服务时可以采用哪些最佳实践时，Buelta 说，“微服务架构成功的关键是每个服务尽可能独立。”
Buelta 解释说，“这里出现的问题是‘如何使服务独立?’发现系统之间的相互依赖关系的最佳方法是从新特性的角度进行思考：如果有一个新特性，是否可以通过修改单个服务来实现？什么样的特性需要协调几个微服务？是常见的需求，还是罕见的需求？没有哪种设计是完美的，但至少有助于做出明智的决定。”
Buelta 建议使用正确的方法做而不是做两次。他补充道，“一旦迁移完成，就很难对微服务的边界进行更改。在项目初期投入的时间是值得的。”
从一个架构模式迁移到另一个架构模式是一个很大的变化。我们问他和他的团队在这个过程中遇到了什么挑战，他说，“最困难的挑战其实是人。它们往往被低估，但转向微服务实际上改变了人们的工作方式。这可不是件容易的事!”
他补充道，“我遇到过这样一些问题，比如必须为开发人员提供足够的培训和支持。特别是，解释一些改变背后的根本原因。这有助于开发人员理解，为什么他们要做出这些让人感到如此沮丧的改变。”
例如，从单体应用迁移的一个常见抱怨是部署时需要协调，而以前是一次单体发布。这需要更多地考虑如何确保向后兼容和最小化风险。这有时不是很明显，需要专门说明。”
