微服务拆分的起点
使用微服务架构模式的思想对目标系统进行拆分之前，我们需要先明白服务拆分起点和终点，以及需要考虑的因素与坚持的原则。所谓起点就是需要清楚拆分的是已有的项目还是新的项目，如果是已有的项目，那么这个项目处于什么样的架构阶段。而终点则是服务拆分后所需达到的架构阶段，以及后续扩展性的考虑，毕竟好的架构不是一次性设计出来的，而是不断进化来的。
不适合使用微服务的业务场景：
- 系统中包含很多很强事务场景的，分布式事务比较难处理，而且由于CAP定律的原因，也无法保证数据的强一致性
- 业务相对稳定，迭代周期长，大半年不需要更新一次版本的，使用微服务意义不大
- 访问压力不大，可用性要求不高，例如一些简单的内部使用的系统
所以说微服务并不是放之四海而皆准的，而且在一些不适合的场景上使用微服务架构只会适得其反，所以我们在考虑架构的时候一定要根据实际的业务场景来设计，否则抛开需求谈架构，不就是在耍流氓吗
康威定律与微服务
微服务可以说是近两年来非常火的新概念，大家都在追，也都觉得很对，但是似乎没有很充足的理论基础说明这是正确的，给人的感觉更多是不明觉厉 。但实际上微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway‘s Law）
据说这篇文章最初投的哈佛商业评论，结果程序员屌丝的文章不入商业人士的法眼，无情被拒，康威就投到了一个编程相关的杂志，所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律（law），只是描述了作者自己的发现和总结。后来，在Brooks Law著名的人月神话中，引用这个论点，并将其“吹捧”成了现在我们熟知“康威定律”。
谈到康威定律，最经常被人摆出来的一句就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
中文大意：
任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
说白了就是，团队在沟通时项目结构是怎么样的，那么项目最终的结构就会是怎么样的，所以项目的结构与团队的沟通是会相互影响的。
我们通过两张图片简单的看一下两种模式下的团队结构：
- 传统架构模式下的团队结构：
- 微服务架构模式下的团队结构：
更多关于康威定律的内容可以参考以下文章：
服务拆分分析
如果一个系统拥有买家端和卖家端，我们可以根据这一点拆分成两个服务。也可以根据业务功能进行拆分，例如可以拆分为商品服务、订单服务、用户服务等，这样拆分的粒度就更细一些。但是代入实际的开发中，如果目标项目比较小，或者团队人数不多，项目迭代也很慢的话，那么这种项目是不需要进行拆分的。
我们在拆分服务的时候，需要满足几个基本点：服务的高可用、可水平扩展以及功能解耦等等。那么如何拆 “功能” 呢，可以参考以下几点：
- 遵循单一职责、松耦合、高内聚原则
- 关注点分离
- 按职责
- 按通用性
- 按粒度级别
如何拆 “数据” ：
- 每个微服务都有单独的数据存储
- 依据服务特点选择不同结构的数据库类型
- 难点在确定边界
- 针对边界设计API
- 依据边界权衡数据冗余
可以参考扩展立方模型去进行拆分：
在微服务架构中，每个服务一般都会拥有各自的数据源，服务和数据的关系如下：
- 先考虑拆分业务功能，在考虑拆分业务对应的数据
- 无状态服务，所谓状态就是只一个数据需要被多个服务共享才能完成一个请求，那么这个数据就可以被称为状态。而依赖这个状态数据的服务被称为有状态服务，反之称为无状态服务
我们来通过一张图片，直观的看一下，服务拆分的前后对比：
原文地址：http://blog.51cto.com/zero01/2171331