微服务的优缺点

本文是对原文进行的补充，因此和原本不完全一致

首先，微服务不是一个名字，而是一个架构的概念，就像Restful不仅仅是描述api的格式，而更多的是描述基于Restful API的架构是一样的。微服务架构（MSA）是对原来的大型系统而言的，通过横向或者纵向、业务或者架构切分，将一个大型的系统分散成很多微型小系统。当系统复杂到一定程度时，几十号人共同维护一个系统的效率很低，而且出问题的风险也很高。

微服务的优点

• 松耦合：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。
• 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。
• 技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。
• 容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
• 扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
• 开发简单，效率高

缺点

• 开发者需要应对创建分布式系统所产生的额外的复杂因素
  1、目前的IDE主要面对的是单体工程程序，无法显示支持分布式应用的开发
  2、测试工作更加困难
  3、需要采用服务间的通讯机制
  4、很难在不采用分布式事务的情况下跨服务实现功能
  5、跨服务实现要求功能要求团队之间的紧密协作
• 部署复杂
• 内存占用量更高
• 数据一致性问题，分布式事务问题
• 服务数量增加，运维数量增加
• 增加了系统间的通信成本