微服务架构的优势和挑战

一 微服务的优势

1 易于开发和维护：一个微服务只会关注一个特定的业务功能，因此它业务清晰、代码量少。开发和维护单个微服务至关简单。而整个应用是若干个微服务构建而成的，因此整个应用也被维持在一个可控状态。

2单个微服务启动较快：单个微服务代码量较少，因此启动会比较快。

3 局部修改容易部署：单个应用只要有修改，就得从新部署整个应用，微服务解决了这样的问题。通常来讲，对某个微服务进行修改，只须要从新部署这个服务便可。

4 技术栈不受限：在微服务架构中，能够结合项目业务及团队的特色，合理选择技术栈。例如某些服务可使用关系型数据库Mysql；某些微服务有图形计算需求，可使用Neo4j；甚至可根据需求，部分微服务使用Java开发，部分微服务使用Node.js开发。

5 按需收缩：可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，能够结合这个微服务的业务特色，增长内存、升级CPU或者增长节点。

综上，单体应用架构的缺点，偏偏是微服务的优势，而这些优势使得微服务看起来简直很是完美。然而完美的东西并不存在，就像银弹不存在同样。微服务存在一些挑战。

二 微服务架构面临的挑战

1 运维要求较高：更多的服务意味着更多的运维投入。在单体架构中，只须要保证一个应用的正常运行。而在微服务中，须要保证几十甚至几百个服务正常运行与协做，这给运维带来了很大的挑战。

2 分布式固有的复杂性：使用微服务构建的是分布是系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

3 接口调整成本高：微服务之间经过接口进行通讯。若是修改某一个微服务API，可能全部使用该接口的微服务都须要调整。

4 重复劳动：不少服务可能都会使用相同的功能，而这个功能并无达到分解为一个微服务的程度，这个时候，可能各个服务都会开放这一功能，从而致使代码重复。尽管可使用共享库来解决这个问题（例如能够将这个功能封装成公共组件，须要该功能的微服务引用该组件），但共享库在多语言环境下就不必定行得通。