分布式和微服务的关系电商系统-微服务架构设计及技术⽅案选型
简单想象⼀下，既然是⼀个电商系统，有⽤户去购买，就肯定得有⼀个⽤户模块，购买什么东西总不是西北风吧，购买肯定是商品吧，省掉购物车，就得有商品模块吧，商品总得有库存吧，库存就暂时跟商品放⼀起吧，什么仓储物流先别管，就当作是虚拟商品好了，反正题⽬也_
没说不能是虚拟商品，购买成功了，那就必须有订单吧，加个订单模块，下完单总得⽀付吧，不付钱⼈家凭什么把东西给你，那就得有个⽀付模块。
简单粗暴，四个模块
⽤户模块，商品模块（库存），订单模块，⽀付模块
好，⼏个模块搞定，外加下单流程图
等等，貌似题⽬说是微服务，既然是微服务就涉及到拆分服务的问题
DDD 领域驱动设计
刚刚确实是梳理了⼀下模块，既然是微服务，就得进⾏服务的拆分，服务怎么进⾏拆分呢，貌似按照刚次梳理模块来划分也是可以，不过这样好像显得我很不是专业，听说现在很多⼈都要使⽤DDD（领域驱动设计）来指导微服务的拆分。
参考DDD的设计，DDD官⽅的架构草图，总体架构分为四层，Infrastructure(基础实施层)，Domain(领域层)，Application(应⽤
层)，Interfaces(表⽰层，也叫⽤户界⾯层或是接⼝层)
微服务结合DDD
不过对于领域设计⽽⾔代码层其实不是最重要，最要的是如何去划分领域，划分好边界。⽽对于微服务⽽⾔，⾮常适合从业务上去划分各个Modules，划分好各个业务板块，微服务 + DDD，个⼈觉得⾸先从微服务的⾓度考虑去划分⼤的业务模块，每个微服务都应该是⼀个可以独⽴部署，各司其职的模块。简单的说，在微服务实际的开发中，结合DDD的思想去划分所有属于⾃⼰的领域。
实施DDD的关键
第⼀点是使⽤通过的语⾔建⽴所有的聚合，实体，值对象。
第⼆点也就是最关键的“建模”
划分“战略建模”，从⼀个种宏观的⾓度去审核整个项⽬，划分出“界限上下⽂”，形成具有上帝视⾓的“上下⽂映射图”
还有⼀个建模“战术建模”，在我们的“战略建模”划分出来的“界限上下⽂”种进⾏“聚合”，“实体”，“值对象”，并按照模块分组。
构建我们电商系统的上下⽂映射图
先来确定我们的战略核⼼的领域是什么，我们的⽬的是什么，作为⼀个电商系统，我们的核⼼肯定是
卖出更多的商品，获取更多订单更多的利润，那么销售可以作为我们的⼀个核⼼的领域。这个作为⼀个明确核⼼域确⽴下来。
确定完核⼼⼦域后，根据对这个领域的理解划分出各个上下⽂，然后根据上下⽂再确定其他的相关领域。
初步我们可以看出围绕销售核⼼域的包含的⼏⼤块内容，价格，销售⽅式，购买的⽅式，已经购买。
然后我们对⽀撑着核⼼域的⼦域也做了划分，⽀撑着核⼼域的有商品域，⽤户域，通⽤域有订单域，
物流域，⽀付域。
回到我们的主题，我们这次没有购物车，也没有各个会员销售价格，把⼀些上下⽂拿掉，并建⽴映射。
领域驱动设计看似简单，其实很难实施，因为在各个环节中都需要对应的领域专家的参加或指导，这样才能设计出最符合实际的上下⽂映射图，⽽且我们花费的精⼒可能相⽐以后的数据驱动开发模式更多，但在整体对项⽬的把控性能上说，领域⽐数据驱动更加抽象，更加的顶层设计，在对应互联⽹的多变情况看得更远。
我们将微服务拆分为5个领域，分别是销售域，商品域，⽤户域，订单域，⽀付域。
完美，接下来就可以开始开发了
等等，兵马未动，粮草先⾏；代码未动，图先⾏，先把时序图画出来
时序图
⼀个简单的下单流程，涵盖了⼏个领域
完美，接下来就可以开发微服务了
等等，微服务的技术栈还未选型
微服务技术栈选型
服务拆分完了，时序图也画完了，可以开始我们的微服务之旅了，⽬前主流的微服务有阿⾥⼤名⿍⿍的dubbo和Spring-Cloud全家桶，还有新浪的Motan。⽐较熟悉的还是dubbo和spring-cloud，也都使⽤过，究竟应该选⽤哪⼀个呢？
因为之前都使⽤过，做点简单，粗暴的总结。dubbo在很早之前就开始使⽤，当时的微服务还没有现在这么⽕，很多理论体系也未完
善，dubbo更像是⼀套rpc整合框架，spring-cloud则更倾向微服务架构的⽣态。相⽐Dubbo，springCloud可以说是微服务⼀整套的解决⽅案，在功能上是dubbo的⼀个超级。 Dubbo和SpringCloud⽐喻，Dubbo架构的微服务就像组装电脑，各个环节⾃由度很⾼。springCloud更像品牌机。
基于不折腾，简单快捷，更倾向选择spring-cloud，ok，就定下来技术栈使⽤spring-cloud，愉快的决定。
等等，就这么草率就决定⽤spring-cloud做为微服务，难道不需要把微服务的利弊先弄清楚吗？
微服务 ： 利和弊
既然选择了微服务，就得知道微服务的利和弊，特别是弊，引⼊了微服务，就等于引⼊了⼀套复杂的
体系，⼀套复杂的体系带来的各种挑战必须事先了解清楚。
利：
1.强模块化边界
我们知道做软件架构，软件设计，模块化是⾮常重要的⼀点，⼀开始我们写程序做软件，我们采⽤类的⽅式来做模块化，后⾯开始采⽤组件或类库的⽅式做模块化，可以做到⼯程上的重⽤和分享给其他
团队来使⽤。微服务在组件的层次上⾯⼜⾼了⼀层，以服务的⽅式来做模块化，每个团队独⽴开始和维护⾃⼰的服务，有明显的⼀个边界，开发完⼀个服务其他团队可以直接调⽤这个服务，不需要像组件通过jar或源码的⽅式去进⾏分享，所以微服务的边界是⽐较清晰的。
2.可独⽴部署
3.技术多样性
弊（或者说挑战）：
1.分布式复杂性
在原来单块应⽤就是⼀个应⽤，⼀个对单块应⽤的架构⽐较熟悉的⼈可以对整个单块应⽤有⼀个很好的把控。但是到了分布式系统，微服务化了以后可能涉及到的服务有好⼏⼗个，⼀些⼤公司可能涉及到的服务上百个，服务与服务之间是通过相互沟通来实现业务，那么这个时候整个系统就变成⾮常复杂，⼀般的开发⼈员或⼀个团队都⽆法理解整个系统是如何⼯作的，这个就是分布式带来的复杂性。
2.最终⼀致性
微服务的数据是分散式治理的，每个团队都有⾃⼰的数据源和数据拷贝，⽐⽅说团队A有订单数据，B
团队也有订单数据，团队A修改了订单数据是否应该同步给团队B的数据呢，这⾥就涉及到数据⼀致性问题，如果没有很好的解决⼀致性问题，就可能造成数据的不⼀致，这个在业务上是不可以接受的。
3.运维复杂性
以往的运维需要管理的是机器+单块的应⽤，分布式系统和单块应⽤不⼀样的是，分布式系统需要很多的服务，服务与服务之间相互协同，那么对分布式系统的资源，容量规划，对监控，对整个系统的可靠性稳定性都⾮常具备挑战的。
只有在清楚了解微服务带来的挑战，明知道⼭有虎偏向虎⼭⾏，才能够真正的胜任挑战，最重要的是，要清楚明了⾥⾯有什么坑，这么避免踩坑。
完美，已经了解微服务带来的好处和挑战，接下来就可以开始开发了 ^ _ ^
等等，微服务还没有做逻辑分层

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。