单体架构的困难/服务拆分的原因
- 由于业务都在一套服务里，导致编译、部署困难
- 代码分支管理困难
- 数据库链接耗尽
- 新增业务困难
- 发布困难
微服务为什么可能变得麻烦？没有做好服务拆分、模块的边界不清、依赖混乱。
微服务拆分的原则
- 原则一，做到单一服务内部功能的高内聚，和低耦合。
- 原则二，你需要关注服务拆分的粒度，先粗略拆分，再逐渐细化。拆分初期可以把服务粒度拆的粗一些，后面随着团队对于业务和微服务理解的加深，再考虑把服务粒度细化。比如说，对于一个社区系统来说，你可以先把和用户关系相关的业务逻辑，都拆分到用户关系服务中，之后，再把比如黑名单的逻辑独立成黑名单服务。
- 原则三，拆分的过程，要尽量避免影响产品的日常功能迭代，也就是说，要一边做产品功能迭代，一边完成服务化拆分。
- 拆分只能在现有一体化系统的基础上，不断剥离业务独立部署，剥离的顺序，你可以参考以下几点：
- 优先剥离比较独立的边界服务（比如短信服务、地理位置服务），从非核心的服务出发，减少拆分对现有业务的影响，也给团队一个练习、试错的机会；
- 当两个服务存在依赖关系时，优先拆分被依赖的服务。比方说，内容服务依赖于用户服务获取用户的基本信息，那么如果先把内容服务拆分出来，内容服务就会依赖于一体化架构中的用户模块，这样还是无法保证内容服务的快速部署能力。
- 所以正确的做法是，你要理清服务之间的调用关系，比如说，内容服务会依赖用户服务获取用户信息，互动服务会依赖内容服务，所以要按照先用户服务，再内容服务，最后互动服务的顺序来进行拆分。
- 原则四，服务接口的定义要具备可扩展性。
微服务拆分方法：
- 基于业务逻辑拆分。将服务划分为“商品”“交易”“用户”3 个服务。
- 基于可扩展拆分。将已经成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。
- 基于核心程度拆分。将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来。
- 基于性能拆分。将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其他服务。常见的拆分方式和具体的性能瓶颈有关，可以拆分 Web 服务、数据库、缓存等。例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。
微服务的坑
- 服务划分过细，服务间关系复杂
- 服务数量太多，团队效率急剧下降，每个人要维护的数目增加
- 调用链太长，性能下降
- 调用链太长，问题定位困难
- 没有自动化支撑，无法快速交付
- 没有服务治理，微服务数量多了后管理混乱
微服务化带来的问题和解决思路
- 服务接口拆分后，接口的响应时间会增加，需要注意上下游服务的超时时间，选择高效的服务调用框架。
- 为了需要知道服务所处机器和端口，需要引入服务注册中心。
- 当某一服务出现性能问题后，会产生大量慢请求，进而影响依赖服务。为了避免这种情况发生，需要进行服务治理，采用熔断、降级、限流、超时控制的方法，使得问题被限制在单一服务中。
- 一条请求的调用链路上，涉及多个服务。为了有效的进行问题定位、确定问题服务的源头，这就需要引入分布式追踪工具，以及更细致的服务端监控报表。
- 服务接口修改版本号问题；服务间的循环依赖问题；微服务化之后一些读库操作变成了远程调用，很多多次读的操作都要修改为批量读取来减少网络耗时，这里的改动还是很大的，甚至一些要求响应时间很高的，还需要做本地缓存。
微服务基础设施
按照下面优先级来搭建基础设施：
- 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
- 接口框架、API 网关：主要是为了提升开发效率，接口框架是提升内部服务的开发效率，API 网关是为了提升与外部服务对接的效率。
- 自动化部署、自动化测试、配置中心：主要是为了提升测试和运维效率。
- 服务监控、服务跟踪、服务安全：主要是为了进一步提升运维效率。
36 | 微服务架构最佳实践 - 基础设施篇 介绍了每个的作用，后续整理的时候再阅读。