微服务和普通应用有啥不同( 二 )
以MVC架构为例，业务通常是通过部署一个WAR包到Tomcat中，然后启动Tomcat，监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。
然而随着业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题。我估计经历过业务和团队快速增长的同学都会对此深有感触。从我的角度来看，大概会有以下几个方面的问题。
部署效率低下。以我实际参与的项目为例，当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次，甚至需要10分钟以上。这也经常被新加入的同学吐槽说，部署测试一次的时间，都可以去楼下喝杯咖啡了。团队协作开发成本高。以我的经验，早期在团队开发人员只有两三个人的时候，协作修改代码，最后合并到同一个master分支，然后打包部署，尚且可控。但是一旦团队人员扩张，超过5人修改代码，然后一起打包部署，测试阶段只要有一块功能有问题，就得重新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与其中，效率低下，开发成本极高。系统高可用性差。因为所有的功能开发最后都部署到同一个WAR包里，运行在同一个Tomcat进程之中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个WAR包中部署的功能。比如我经常遇到的一个问题，某段代码不断在内存中创建大对象，并且没有回收，部署到线上运行一段时间后，就会造成JVM内存泄露，异常退出，那么部署在同一个JVM进程中的所有服务都不可用，后果十分严重。线上发布变慢。特别是对于Java应用来说，一旦代码膨胀，服务启动的时间就会变长，有些甚至超过10分钟以上，如果机器规模超过100台以上，假设每次发布的步长为10%，单次发布需要就需要100分钟之久。因此，急需一种方法能够将应用的不同模块的解耦，降低开发和部署成本。想要解决上面这些问题，服务化的思想也就应运而生。
什么是服务化？这里我就不谈一些官方的、教条主义的概念了。在我看来，用通俗的话来讲，服务化就是把传统的单机应用中通过JAR包依赖产生的本地方法调用，改造成通过RPC接口产生的远程方法调用。一般在编写业务代码时，对于一些通用的业务逻辑，我会尽力把它抽象并独立成为专门的模块，因为这对于代码复用和业务理解都大有裨益。
在过去的项目经历里，我对此深有体会。以微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户模块。当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连接对应的资源。一旦任何模块的代码出现bug，或者依赖的资源出现问题，整个单体应用都会受到影响。
为此，首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以RPC接口的形式对外提供服务。微博和消息模块调用用户接口，就从进程内的调用变成远程RPC调用。
这样，用户模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合。进一步的可以再把消息模块也拆分出来作为独立的模块，交由专门的团队来开发和维护。
可见通过服务化，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题。
什么是微服务？从2014年开始，得益于以Docker为代表的容器化技术的成熟以及DevOps文化的兴起，服务化的思想进一步演化，演变为今天我们所熟知的微服务。
那么微服务相比于服务化又有什么不同呢？
在我看来，可以总结为以下四点：
服务拆分粒度更细。微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。服务独立部署。每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个Docker实例，每个Docker实例可以部署一个微服务的代码。服务独立维护。每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。服务治理能力要求高。因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。
推荐阅读
- 大连暂停小诊所和村卫生室等相关医疗服务
- “他是我第一个会说普通话的老师”：一对师生折射青海山村蝶变
- 江苏高考■江苏省发布《2021年普通高校招生考试安排和录取工作实施方案》
- 长春评选“网络奋斗者”：互联网成更多普通人创业工具
- 八旬老人义务剪发50余载带领“银发服务队”温暖一座城
- 互联网怎样解决“家政服务上门速度慢”的问题
- 服务区|南通交警走进高速服务区开展主题宣传活动
- 大丰|盐城大丰开通智慧养老服务平台 已完成17万次上门服务
- 普通车|德系商务风对阵美式运动范 迈腾 VS 迈锐宝XL
- 汽车|看了中消协4S店服务测评调查结果，终于知道法系车为啥卖不好了