微服务的理解

近年来，微服务越来越成熟，企业项目也大都向微服务方向靠拢，这篇随笔来介绍一下微服务跟传统服务的区别。

 

传统服务

假如你要开发一个web后台服务，大部分人一开始都会将所有功能实现并放到一个进程内。project的代码编译后会产生一个war包，将war包丢进tomcat中就可以运行，这是一种典型的传统架构，传统架构对也有较好的模块划分以及清晰的分层设计。

传统架构的好处在于：

1、物理架构简单，单机搞定。

2、一个project搞定。

3、容易部署，将war放入tomcat中运行即可。

4、容易测试，不用跨服务。

随着时间推移和业务需求的不断新增，如果继续用传统项目开发，你的应用慢慢变得臃肿，逻辑复杂，难以梳理，后期维护成本过高。自己的应用从最开始的简单清晰慢慢变成一头桀骜不驯的猛兽。这时传统服务的就会使你陷入一场灾难：

1、代码难以理解，导致修改困难。各种代码逻辑盘根错节，你渐渐发现任何敏捷开发的尝试，都会失败。特别是那些不注重设计与架构分层的，急于应付业务的开发者，加入各种定制逻辑，其实很可能是在为自己挖坑埋地雷，让自己在后继开发过程中瞻前顾后，寸步难移，加大项目风险。往往一次修改都可能会临一次不小的重构。

2、服务启动时间长。 随着功能的增多与业务加重，越来越多数据加载、预处理工作在服务启动的时间进行。这就会导致服务的启动时长变长，甚至一次启动要花费十几分钟。同样在本地做测试时，每次测试会带动繁重的加载处理操作，严重影响开发效率。

3、服务的稳定性被拉低。因为功能模块逐渐增加、模块问关联逻辑愈加复杂，而任何模块本身bug与它们交互时带来的bug及出错情况都可能会把你整个服务搞挂。

4、多人协同开发困难，不便于团队分工。单体架构服务往往更适合一个人去开发。正常情况下，单体架构服务在IDE中以一个project的形式存在，多人开发一个project时，每个人难以把整体掌握全局逻，存在风格冲突、引入技术重叠字、修改冲突等一系列问题。

 

微服务

为解决上述问题，微服务架构应运而生，与其构建一个臃肿庞大、难以驯服的猛兽，还不如及时将服务拆分。微服务的核心便是将服务拆分和解耦，降低复杂性，微服务强调将功能合理分解，尽可能保持每个服务的功能单一，从而各个服务做轻、灵活、可复用。

微服务的好处在于：

1、每个服务更小更轻，每个服务的功能更加清晰明了，代码易于阅读。即便人员变动，代码交接，也不会有太大的困难。服务变小，启动速度也会变得更快，开发效率也会得到提升。

2、微服务的架构更加适合团队分工。对一个成熟的程序猿来说，一个微服务最好一个人来开发，避免沟通成本及提交代码时造成的冲突。微服务架构对传统架构拆分完后，可以根据每个程序猿的技能方向分配开发任务，确保技术架构稳定的同时，也提供团队之间良好的合作方式。

3、微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混为一谈。

 

4、微服务可以让你使用各种各样的技术或者语言来进行开发。

 

总之，微服务的理解主要在于一个微字上边，微就是小，与其叫微服务，还不如叫小服务，简单易懂，顾名思义。