微服务
微服务 (MicroServices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。
微服务的优点包括：
- 逻辑清晰。拆分大单体后，单个服务更容易开发、理解和维护；
- 技术异构。每个服务可以分配给专门的开发团队，开发者可以自由选择开发技术；
- 简化部署。开发者不再需要协调其它服务部署对本服务的影响，可以加快迭代速度；
- 扩展灵活。每个微服务可以根据各自需求进行扩展。
当然也存在缺点：
- 微服务间需要统一的通信机制；
- 带来的分布式事务不一致问题；
- 增加测试复杂度，需要考虑强弱依赖、降级、限流等问题；
- 运维复杂，由于服务较多，需要统一的运维平台支持；
- 增加了服务间的调用成本。
拆分原则
- 符合团队结构。康威定律告诉我们组织沟通的方式会在系统设计上有所表达。我们设计的系统架构是服务于我们的组织架构的，二者应相辅相成。
- 单一职责。业务边界清晰，一个服务对应一个业务，服务间正常应该是单向依赖。
- 高内聚低耦合。对于业务变更，应该很少出现既可以在这个服务上实现也可以在那个服务上实现这种摸棱两可的情况。应实现最大化复用，最小化影响。
- 演进式拆分。刚开始不要划分太细，不要想着一口气吃成胖子。
如何拆分
业务维度
根据业务主要可以采用 DDD 的战略分析的方式，通过分析子域，划分界限上下文的方式划分微服务。本质上是将业务比较独立，或者关联比较紧密的业务拆分为一个微服务。
技术维度
- 性能
比如秒杀相关接口，性能要求非常高，一个或几个接口可以放在一个微服务内。
-
架构
如业务网关、日志服务、注册发现中心等都是一个单独的微服务。
-
发部更新频率
例如营销服务，业务变更随着玩法不断迭代，发布频率高，适合单独一个微服务。
-
技术异构
一些业务可能采用不同的技术栈实现更有优势，可以单独成为一个微服务。
-
根据团队分工
每个微服务需要的足够团队人数支撑，一般是三个左右（一个说法是一人没有备份，两人如果一人请假，另外一人压力比较大，三人稳定一些）；另外还需要考虑运维、测试人员等，服务拆分对他们带来的影响如果比较大，尤其是运维团队，那么建议还是维持单体或者服务拆分的少一些。
总结
服务的划分是微服务设计的第一步，但架构不应只聚焦于技术，人的因素，团队、项目的因素往往更重要，所以实践时遵循上述原则的同时更要灵活机动，因地制宜，原则指明的是大的方向，对于无法掌握的项目，尽量采用演进式拆分，避免为了拆分而拆分而对业务产生负收益。