微服务架构系列 - 实战篇：服务拆分原则及系统架构设计
- 1 min微服务架构系列（四十一）
微服务可能存在的坑
单体应用运行一段时间后，随着业务的增长，对系统性能和并发性要求越来越高，这个时候就面临着微服务重构的选择，在概念篇中花了大量篇幅介绍了微服务架构相较于单体应用的优势和可能的陷阱，在进行微服务重构之前，我们必须反复权衡并且做好必要的基础设施准备以应对新架构下面临的新问题，而不是觉得微服务现在火脑袋一热就开始着手微服务重构。
在实战篇中，我们再度结合实际项目来探讨下微服务架构的最佳实践，回顾下微服务可能存在的坑，主要包含以下几点：
- 过分强调’微‘，致使服务拆分过细，服务数量太多，导致服务间关系复杂，系统复杂度上升，人力和维护成本变高；
- 原本的单体同进程间服务调用变成远程不同进程间服务调用，调用模式从内存调用变成网络调用，如果调用链路过长，反而会导致性能下降，响应时间变长，同时问题定位变得愈发困难；
- 基础设施不健全，没有必要的服务监控和治理，导致服务管理混乱，原本设想的轻量级微服务变成一堆乱麻，此外，自动化测试和部署支持也要更上，否则服务间有依赖的话无法实现快速交付。
服务拆分和粒度划分原则
接下来，我们将就这几个问题做好规划，首先要解决的是服务拆分和粒度划分。
关于服务拆分和粒度划分，建议基于业务类型和团队规模进行拆分，从业务类型上先做大的切分，比如商品、用户、交易等，然后具体到某个业务，再根据团队规模进行划分，基于团队规模进行拆分时，可以参考两个著名的理论：
- 一个是亚马逊 CEO 贝索斯在定义团队规模时提出的“两个披萨”理论，即每个团队的人数不能多到两个披萨都不够吃的地步。
- 一个更具实操性，那就是“三个火枪手”原则，即一个微服务三个人负责开发。如果业务继续增长，团队规模扩大，再将已有的微服务进行拆分，比如商品最初由三个人开发，后来随着业务玩法的增多，又衍生出拼团、特卖、海外购等不同的子业务，相应的，团队规模也在扩大，则可以对现有的商品微服务继续拆分，所以，微服务的拆分是伴随着业务和团队的规模在动态变迁的。
那为什么是三个人，不是四个人，两个人呢？从系统规模来说，三个人负责开发一个系统，复杂度刚好达到每个人都能全面理解整个系统，又能够进行明确分工；从团队管理来说，三个人可以形成一个稳定的备份，不会因为某个人离开导致系统无人维护、无法支撑；从技术角度来说，三人小组既能够形成有效的讨论，又能快速达成一致意见。
不过，需要注意的是”三个火枪手“原则主要应用于微服务设计和开发阶段，如果经过一段时间，微服务已经稳定运行进入维护期，则留下一个人维护一个微服务即可。
系统架构设计
服务拆分粒度确定之后，接下来，需要对系统进行设计和架构，并围绕这个设计方案进行服务开发和基础设施建设。以我们在概念篇：微服务架构总体设计 中的总体设计为蓝图，略作调整，形成本次微服务重构的技术架构图：
注：初步架构设计图，后续可能有微调。
这里需要注意的是，微服务重构往往伴随着数据库的垂直拆分，拆分后的微服务对应业务DB也需要拆分出来，这样，不同微服务就实现了数据库操作的隔离，从而提高了系统的可用性。另外，这里将业务DB放到微服务层是为了标识数据库的独立性，实际开发中，数据库仍然归于基础服务层，不同微服务通过统一的数据库中间件建立与对应数据库的连接。
此外，本系列教程微服务实战侧重微服务开发部分，基础服务部分的消息队列、缓存、数据库、文件系统、搜索引擎等功能在具体开发会通通简化，不会详细展开，也不会做分布式部署，但是 PHP 应用层、注册中心、Go 微服务层会做集群部署和负载均衡演示。
下一篇教程，将给大家介绍此架构图中不同功能组件的技术选型和方案选择。