Java生鲜电商平台-微服务架构利弊分析（生鲜小程序/APP）

java生鲜电商平台-微服务架构利弊分析（生鲜小程序/app）

 

java生鲜-微服务架构利弊分析

 

项目名称	内容	编写人	编写时间	备注
xx生鲜		x总	2020-02-26	v1.0

 

1.   微服务是什么？

开篇之前先声明我对微服务的几点态度：

1.架构模式有很多，微服务不是唯一的选择也不是什么银弹。国内绝大多数中小公司引入微服务都是在盲目追新，也能看出做此种技术选型的工程师基础架构素质的不足。

 

2.“.你必须长的足够高才能使用微服务”。微服务基础设施，尤其是容器技术、自动化部署、自动化测试这些不完备，微服务形同虚设，不会带来什么质的提升。

 

3.微服务架构的关键不在于具体的实现，而在于如何合理地划分服务边界以及组织架构是否相匹配。不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。

2.   为什么采用微服务?

是否选择微服务取决于你要设计的系统的复杂度。

微服务是用来把控复杂系统的，但是随之而来的就是引入了微服务本身的复杂度。

 

需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案，但是仍然是有不小的成本的。

生产力和复杂度的关系如图所示，可见系统越复杂，微服务带来的收益越大。此外，无论是单体应用还是微服务，团队的技能都需要能够把控住。

 

除非管理单体应用的成本已经太复杂了(太大导致很难修改和部署)，否则都不要考虑微服务。

大部分应用都应该选择单体架构，做好单体应用的模块化而不是拆分成服务。

因此，系统一开始采用单体架构，做好模块化，之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰，再重构为微服务架构是一个合理的架构演化路径。

 

四个可以考虑上微服务的情况：

1.多人开发一个模块/项目，提交代码频繁出现大量冲突。

2.模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求太多，风险大。

3.主要业务和次要业务耦合，横向扩展流程复杂。

4.熔断降级全靠 if-else。

3.   微服务架构(生鲜电商)

          参考其他的文章：http://www.cnblogs.com/jurendage/p

4.   微服务的优点

通过上面的架构图，我们可以知道，生鲜电商可以根据模块的划分如下：

分为用户服务，商品服务，购物车服务，订单服务，支付服务，售后服务，促销服务等，服务与服务之间是互相的独立的，互相不影响，而且各自都有自己的扩展性与隔离性. 不会因为某一个服务而导致整个系统架构的不可用，有点非常明显.

总结一句话：优点：模块的强边界;独立部署;技术选型的多样性

5.   微服务的缺点

 通过上面的架构图，我们可以知道，根据服务的拆分，我们发现生鲜电商分了很多的服务，把原来的功能都独立起来，形成了强有力的微服务架构.

 但是每个服务的维护与开发都需要2-3个人进行开发与维护，如果生鲜电商有10个模块，团队规模过大，沟通成本很高，而且一旦生产环境出了问题，需要联合起来进行排查，整个交易路线过于长，不利于维护.

整体而言，增加了研发成本，运营成本，服务器成本，沟通成本，排查问题的成本

缺点：分布式带来编程复杂度，远程调用的消耗;舍弃强一致性，实现最终一致性;操作复杂性要求有一个成熟的运维团队或者运维基础设施。

 

实战说明：1.比如用户突然下不了订单了。系统预警后，需要找到订单服务的相关人员，进行问题的排查，这个需要时间，

                  2.假如问题定位后，发现是由于商品的价格设置有误，导致订单无法保存，这个就需要去找商品服务的人员协助，

                  3.商品人员发现技术没问题，是运营人员参数配置出错了，导致商品这块的价格有问题，最终无法下单。

                  4.最终找下运营人员，把问题解决，整个流程就又通了。

6. 决策权衡微服务

   写到最后，我不建议项目第一期做微服务架构，这两年微服务架构在大公司变成了大小中台战略，因为其有复杂性非常的高，而且需要人专注某一个具体的模块与领域，提高工作效率.（淘宝，天猫，京东都采用这种，巨无霸公司）

    xx生鲜，根据我6年生鲜生涯的经验来看目前我认为其复杂性与功能性要求，不需要杀鸡用牛刀. 如果以后有需要可以进行针对化的优化与业务处理.

 

最终实例如下：

     

 

实际运营截图：

 

联系qq：137071249

qq群：793305035