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