一.认识微服务
 

1.单体服务架构的特点

从软件开发的角度来看，服务就是进程外的组件，与其他组件以明确的接口进行交互，类似于
进程内的函数调用。从可读性、可理解性、可维护性的角度出发，我们倾向于写小函数，避免写过
于复杂的大函数，因为大函数容易出错，难于维护和修改。若干功能明确、职责单一的小函数有利
于重用，提高开发效率。
 

同理，服务也一样。单体架构：将业务所有功能集中在一个项目中开发，打成一个包部署。

比如，我们起初开一个小饭馆，老板除了兼任厨师和服务员之外，可能还负责采购、收银以及
打扫店面卫生，这是一个典型的单体服务。单体服务并非不好，店小利薄，提供的菜品较为简单，
一个人也应付得来。然而生意兴隆、规模扩大之后问题就来了，老板分身乏术，就需要雇用厨师、
服务员、收银员、采购员、保洁员等来共同做好饭馆服务，于是一个单体服务便拆分为多个微服
务。

软件服务与此类似，当服务单一、规模小、逻辑简单时，用一个单体服务就挺好。在服务多样
化、规模增大、逻辑变复杂之后，单体服务就不再适合了，缺点一一呈现。
 

●复杂程度高。维护成本越来越高，各个模块之间边界模糊，一个模块的改动可能导致整个服务出现
问题，一点内存泄漏、一处指针错误就会让整个服务停机。
 

●水平扩展困难。单机的容量有限，而且缺乏弹性，一荣俱荣，一损俱损。垂直扩展受到硬件约束,
水平扩展也比较困难。
 

●性能优化困难。单体服务支持着多个业务，多种逻辑可以交织在一起，互相影响，互相争用系统资
源，在服务性能调优时很难取舍，要做出令人满意的平衡很难。
 

●可测试性变差。复杂性变高、模块众多、耦合在一起的代码必然造成测试困难。