微服务架构的优缺点和拆分

单体式的架构更适合轻量级的简单应用，微服务架构适合大型、大团队、敏捷迭代型项目。
后台架构的演变：单体结构（巨无霸） --> Dubbo 单体结构（小巨无霸） --> 微服务普通结构 --> 微服务中台结构

微服务架构更加敏捷，如果单体结构的话，任何一次改动的发版，都要重启整个应用。系统之间的耦合度降低

1. 代码的独立。各自团队负责各自微服务的代码维护，互相不会影响，也不容易造成代码冲突。也包括code review、还有功能测试。下载代码也不需要下载全部的代码。如果共用代码，有的功能没有开发好，有的小功能已经开发好了，已经开发好的功能没法单独上线。除非采用很多分支，拆分上线。
2. 微服务系统间的独立。系统之间相对独立，非核心系统的发版或者异常，不会影响整个系统核心业务的运行。更加敏捷。
3. 数据的独立。各自服务负责各自的数据，特别是机密数据不需要开放给无关的人员。
4. 业务的切分，降低了单个服务的复杂性，负责某一服务的开发人员，只需要了解自己相关的业务。快速上手，focus在各自的业务上。
5. 人的独立。团队管理更方便。比如招一个人负责商品的服务，则该小伙伴不需要了解支付、优惠券、库存相关的业务场景，只需要清楚商品相关的业务规则就可以了

微服务架构缺点：

1. 分布式事务的问题
2. 提升了运维的难度（发版、问题排查、配置管理、监控) -->催生了Jenkins + ELK +Spring Config + Spring Admin + Docker
3. 单体结构资源利用率比较高
4. 性能降低。单体架构 函数都是内部调用，微服务的间通过REST、RPC等形式进行交互，通信的时延会受到较大的影响。

微服务的拆分：项目拆分 --> 业务拆分（中台）--> 功能拆分
业务拆分：订单系统、支付系统、用户中心、卡券系统、商品系统 等等
功能拆分：支付portal系统 + 支付admin管理系统