微服务架构与单体应用对比

微服务架构的优点

相对单体应用架构来说，微服务架构有着显著的优点。但是，微服务并非是完美的，使用微服务也为我们的工作带来一定的挑战。

微服务架构有如下优点：

  微服务虽然有很多吸引人的地方，但是使用它还是有一定的代价的。

微服务架构有如下缺点：

运维要求比较高，更多的微服务，意味着更多的运维工作投入，在单体架构中，只保证一个应用正常运行即可。而在微服务架构中，你需要保证几个或者几十个服务能正常运行与协作。
分布式固有的复杂性，使用微服务的架构属于分布式系统，系统的容错，网络延迟，分布事务都会带来比较复杂难度；
接口调用成本高，微服务之间是通过接口通讯进行完成的，如果修改了某个微服务的api，可能所有使用了该接口的微服务都需要做调整；
代码冗余，很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这时就有可能会产生相同功能冗余的问题。（建议：有些功能类似的封装成功能组件，需要该功能的微服务，引用该组件就可以）；

和数据库设计表设计一样，微服务设计也有一定的设计原则，这些原则指导我们更加合理的设计我们的微服务架构。

微服务架构设计规则如下：

单一职责，指一个微服务只关注整个系统功能中单独、有边界的一部分，单一职责可以帮助开发人员更加优雅地开发、更敏捷的交付功能。
服务自治原则，服务自治是每个微服务应该具备有独立的业务能力、依赖于运行环境，在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署都应该可以独立运行，而不应该依赖其他服务；
轻量级通信机制，微服务之间应该通过轻量级的通信机制交互。轻量级通信机制，首先满足条件，体量较轻，没有复杂的依赖，其次是夸语言、夸平台。例如我们熟悉的rest协议，就是一个典型的“轻量通信机制”，而java中的rmi协议则不符合轻量级通信机制的要求了，因为它仅限制java语言的开发服务使用；
微服务粒度划分，微服务粒度划分是一个难点，也是经常争论的焦点。我们应该根据具体项目需求合理的粒度划分微服务，而不是一味的把服务做小。有一个误区，我们不能以代码量的多少当作划分微服务的依据，因为不同的微服务中本身业务复杂度不同，代码量就也不同了；

相对单体应用来说，微服务应用开发复杂度比较高，现在也有比较好的开发框架支持，下面我们从开发和运行平台两个维度考虑挑选技术框架。

开发框架的选择，可使用springcloud 作为微服务开发框架。首先springcloud具备有开箱即用的优点，可以大大提升了开发效率，更为重要的是，springcloud为微服务提供了一套完整的解决方案。当然现在市场也有其他开发框架：如 duboo、armada 等。
运行平台，微服务并不受限运行平台，微服务部署在物理pc server或者阿里云、腾讯云、windows、Linux都是可以的。

批注：猴子们，好好加油！！！

链接: link.

图片: Alt