微服务入门

1. 单体化架构缺陷

在日常我们开发的小团队中，由于我们开发规模比较小，可能都使用的是单体化架构，团队的开发和运维成本都可控。然而随着业务规模的不断扩大，或者是团队人员不断扩张，单体化架构可能会出现问题，如下：

• 部署效率低下：当单体应用的代码越来越多，依赖资源越来越多，应用编译打包、部署测试一次，可能需要10分钟以上。
• 团队协作开发成本高：当团队成员人员扩张，超过5人修改代码，然后一起打包部署，测试阶段只要出现了一处问题，就得重新编译打包部署，然后测试人员需重新测试，效率低下，开发成本极高。
• 系统高可用性差：系统所有功能最后都部署到同一个WAR包里，运行在同一个Tomcat进程中，一旦某一功能涉及的代码或者资源有问题，就会影响整个WAR包中部署的功能。比如某段代码不断在内存中创建大对象，并且没有进行回收，部署到线上运行一段时间后，就会造成JVM内存泄漏，异常导致整个JVM进程中的所有服务都不可用。
• 线上发布变慢：对于java来说，一旦代码膨胀，服务启动就会边长，有些甚至超过10分钟以上如果机器规模超过 100 台以上，假设每次发布的步长为 10%，单次发布需要就需要 100 分钟之久。

因此，急需一种方法能够将应用的不同模块的解耦，降低开发和部署成本。

2. 什么是服务化

用通俗地话说，服务化就是把传统的单机应用中通过JAR包依赖产生的本地方法调用，改造成通过rpc接口产生的远程方法调用。一般在编写业务代码时，对于一些通用的业务逻辑，尽量把它抽象并独立成为专门的模块，因为这对于代码复用和业务理解都大有裨益。

在一体化架构中，比如微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户模块。当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连接对应的资源。一旦任何模块的代码出现 bug，或者依赖的资源出现问题，整个单体应用都会受到影响。

因此将各个模块从单体应用中拆分出来，独立成一个服务部署，以RPC接口的形式对外提供服务，将独立出来的各个模块交由专门的团队来开发和维护。由此可见，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题。

3. 微服务相比于服务化有什么不同

随着以Docker为代表的容器技术的成熟以及DevOps文化的兴起，服务化的思想进一步演化，演变为今天熟知的微服务。

微服务相比于服务化不同点在于：

• 服务拆分粒度更细：微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其它模块都没有关系，那么就可以拆分为一个微服务。
• 服务独立部署：每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个Docker实例，每个Docker实例可以部署一个微服务的代码。
• 服务独立维护：每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。
• 服务治理能力要求高：因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。