微服务架构系列主题：微服务架构的利与弊

前言

该文档主要介绍微服务架构的优点和缺点，让你在选择微服务架构之前，有所参考，来帮助你判断你的项目是否适合微服务架构。

微服务架构的优点

• 每个服务足够内聚，足够小，代码容易理解，开发效率高
• 服务直接可以独立部署，让持续部署成为可能
• 每个服务可以各自进行水平和垂直扩展，而且每个服务可以根
• 据需要部署到合适的硬件和软件上
• 容易扩大开发团队，可以根据每个组件组织开发团队
• 提高容错性，一个服务的问题不会让整个系统瘫痪
• 系统不会长期限制在某个技术栈上
• 降低成本。可尽量复用已有功能，避免重复造轮子。可以大大减少项目建设过程的调研、设计、开发、测试、运维的成本。
• 易于开发与维护：一个微服务只关心一个特定的业务功能，所以他业务清晰，代码量较少。独立开发部署服务。
• 局部修改容易，所以开发上线速度和灵活性
• 更高的代码质量
• 获得围绕业务功能创建/组织的代码
• 提高生产力。开发人员专职自己的微服务开发，对业务和代码都熟悉。
• 更容易扩展
• 技术栈不受限：每个服务可用不同的开发语言
• 按需伸缩：可根据不同的需求，实现细粒度的拓展。
• 为多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。
• 持续集成和持续交付的应用大大提高生产力。提高开发人员生产力， 开发人员只需要将代码推送到代码仓库即可。该代码将被集成，测试，部署，再次测试，与基础功能（Maven依赖）合并，经过质量审查，并准备以极高的信心进行部署。减少了手动操作的环节，极大的提高了重复工作的效率。

微服务架构的缺点

• 运维的技术复杂度和相应的运维成本（测试、变更、部署），必须建立开发运维一体化机制Devops
• 必须有完备的监控手段和自动化恢复手段
• 分区数据库可能带来的业务数据同步与一致性问题
• 微服务的接口将成为变更的敏感位（尽量保持接口的稳定性，不能经常变化入参和出参）
• 运维要求高：服务更多意味着运维的投入，单体应用只需保证一个应用的正常运行，而在微服务中，需要保证几十上百的服务正常运行与协作。服务越小，独立性更好，但是相应的服务数量就越多。每个服务都需要独立的配置、部署、监控、日志收集等，成本呈指数级增长。需要更高的自动化运维策略。
• 微服务应用作为分布式系统带来了复杂性。当应用是整体应用程序时，模块之间调用都在应用之内，即使进行分布式部署，依然在应用内调用。可是微服务是多个独立的服务，当进行模块调用的时候，分布式将会麻烦。
• 多个独立数据库，事务的实现更具挑战性。
• 依赖管理复杂
• 测试微服务变得复杂，当一个服务依赖另外一个服务时，测试时候需要另外一个服务的支持。