使用原因
- 新版本上线时需要反复确认所有代码是否提交, 繁琐
- 将微服务和容器化与devops结合, 能更好的快速迭代
单体架构的问题
- 随着项目增大, 依赖增多, 编译时间长，分模块编译
- 团队协作成本高, 代码合并后编译后有问题, 要重新打包部署
- 系统可用性差, 一个功能代码出现问题, 整个程序都受影响
- 线上发布慢, 随着代码量增加, 服务启动时间变长
例如：
一个功能产生内存泄露，会导致整个系统崩溃。
服务化
将传统的但体积用用通过jar包依赖产的本地方法调用, 改造成通过RPC接口产生的远程方法调用。一般在编写业务代码时，对于一些通用的业务逻辑，尽力把它抽象并独立成为专门的模块。
例如:
微博包含内容、消息、用户模块，内容依赖消息模块，消息和内容都依赖用户模块，如果其中一块出现bug，系统就会受到影响。
将用户模块服务化，独立出来，已RPC接口提供服务，消息和内容调用接口。
优点：可以将业务分离，用户模块单独开发\
微服务
- 服务拆分颗粒度更细，服务化到每个子模块，只要模块依赖的资源与其他模块无关，就可以拆分为一个微服务
- 服务独立部署，每个微服务都独立打包部署，互不影响，比如每个doker实例放一个微服务代码
- 服务独立维护
- 服务治理能力要求高
例如：通过微服务化，将这三个模块变成三个独立的服务，每个服务依赖各自的资源，并独立部署在不同的服务池中，可以由不同的开发人员进行维护。当某个服务需求变更时，只需要修改评论业务相关的代码，并独立上线发布
何时进行服务化
- 进行可行性开发测试后，增加细化功能
- 开发人员超过10人
服务化的两种方式
- 纵向切分，从业务维度拆分，关联比较密切的拆分为一个（有依赖关系），功能独立的拆分为另一个
- 横向切分，类似于AOP，一个功能被其他功能调用，但是其依赖不和其他业务耦合，拆分为一个
例:
社交 App，无论是首页信息流、评论、消息箱还是个人主页，都需要显示用户的昵称。假如用户的昵称功能有产品需求的变更，如果我把用户的昵称功能单独部署成一个独立的服务，那么只需要上线这个服务即可，其他服务不受影响，开发和上线成本就大大降低了。
有频繁的需求变更的可以和基本稳定的进行拆分，形成不同的微服务
