针对现在开发用的框架(SSM+Dubbo)，自己进行了一些思考；这些问题应该是当系统在大流量，高并发，分布式情况下需要考虑一些问题，自己在对服务拆分的时候一些思考的记录下来，与大家共享；
一、服务调用
1、服务之间调用的关系是否清晰合理？
这是考量一个系统拆分的服务是否合理的一个重要指标；好的架构设计，各个服务职责明确，服务间调用关系清晰明确；反之则是一个梦魔；
2、如何拆分服务是和业务密切相关？
我们根据云平台的业务将我们的系统拆分成四大服务，服务之间通过接口调用，自己服务禁止通过查数据库的方式直接查其他服务的库，必须通过接口；
二、Facade层的作用以及这样设计的好处
1、Facede层作用
我们的项目架构是在service中增加了Facade层，那么这层是用来干什么的那？它就是用来为其他服务提供接口实现，如果是自己项目的service之间调用，则不必走Facade；
2、这样做的好处
代码上将对外和对内的进行隔离，易于排错，遇到问题，根据Facade中是否有该接口可以定位是外部系统调用出错，还是内部系统出错。
三、抽出BaseService遇到一些问题
1、状态码设置：如何根据不同的系统设置不同的状态码？需要在抽象的基础上在实现个性化；
2、事务的控制：事务一直是分布式系统中最具挑战性的事情，通常做法如下：
（1）根据业务场景判断是需要强一致性还是最终一致性（一般情况下是最终一致性）；
（2）最终一致性，我们可以利用消息队列异步补偿等机制来实现数据的最终一致性；
（3）强一致性，这种场景的业务比较少，如果真的遇见可以通过第三方的框架来实现比如：阿里的GTS等；
1、多思考，多实践；
2、凡事有利必有弊，需要我们权衡，比如系统服务化后在带来服务扩展性好等优点的同时也带来了事务等问题；需要我们在设计的时候根据现在项目所处的阶段以及开发人员的水平，去平衡；
当年的春天 认证博客专家 分布式 Spring Redis 6年Java互联网研发经验，坐标北京；擅长微服务和中间件。