微服务优缺点对比

我们为什么要使用微服务这种架构呢，在使用这种架构的时候最首要一点就是要考虑场景。我在这里简单说一下我总结过的优缺点。

优点：

1，部署简单

当我们采用微服务架构以后，每个服务只承担少数职责，从而每次只需要发布发生修改的系统，其他系统依然能够正常运行，波及范围较小。此外，相对于单服务应用而言，每个微服务系统修改的代码相对较少，从而部署后出现错误的概率也相对较低。微服务还能降低系统的复杂性，熟悉一个错综复杂的系统 全部功能乃至于重构，是很多架构师最头疼的一点，代码的重复堆砌和开发的随意性，让一个一开始就简单的系统越来越复杂，往往牵一发而动全身。

2，易于扩展

当我们使用了微服务架构后，如果某一项服务的性能到达瓶颈，那么我们只需要增加该服务的节点数即可，其他服务无需变化。这种扩展更加具有针对性，能够充分利用计算机硬件/软件资源。而且只扩展单个服务影响的范围较小，从而系统出错的概率也就越低。微服务在重构后也能通过横向扩展，以较低的成本来增大系统的吞吐量，能够针对系统的瓶颈服务更有效的使用资源。

3. 技术异构性

对于单服务应用而言，一个系统的所有模块均整合在一个项目中，所以这些模块只能选择相同的技术。但有些时候，单一技术没办法满足不同的业务需求。如对于项目的算法团队而言，函数试编程语言可能更适合算法的开发，而对于业务开发团队而言，类似于Java的强类型语言具有更高的稳定性。然而在单服务应用中只能互相权衡，选择同一种语言，而当我们使用微服务结构后，这个问题就能够引刃而解。我们将一个完整的系统拆分成了多个独立的服务，从而每个服务都可以根据各自不同的特点，选择最为合适的技术体系。

4，降低资源的耦合性

我认为微服务的一个先决条件就是独立，就是数据源控制权的唯一入口，这样子我们可以根据来源做一些降级限流

缺点：

1，微服务将原来的函数式调用改为服务调用，不管是用rpc，还是http rest 方式，都是增大系统整体延迟。这个是再所难免的，这个就需要我们将原来的串行编程改为并发编程甚至异步编程，增加了技术门槛。

2，微服务需要更多的技术全局考虑，比如服务之间的通信，调用链的监控，以及资源的分配，这个在服务拆分之前最好能考虑清楚，否则真的只是代码的拆分，违背的微服务的本意