Java生鲜电商平台-生鲜电商中微服务架构与集群模式如何选择？(小程序/APP)
说明： Java生鲜电商平台-生鲜电商中微服务架构与集群模式如何选择？其实微服务对于开发生鲜电商系统的人来说已经不算很前卫的概念了，它已经成为了面试的主角。很多同学私下问巨人大哥要一些微服务的资料，大部分都是为了面试，面试造火箭，上班紧螺丝.......。学归学，落地实践的时候一定要小心。
以下是我的一些见解，不一定对，但是的确是我的一些见解，如有不同意的朋友，欢迎留言：加群聊或者留言评论
1. 初创项目不宜微服务
微服务系统架构
某生鲜电商初创公司，2019年项目立项就使用了当时火热的SpringCloud Alibaba。当时的团队只有10几个人，其中后台开发只有5个人，在这样的情况下却采用了微服务架构。前期业务的设计不合理，导致项目的业务边界不清晰，随着业务迭代出现了大量业务耦合，为了获取一个完整的数据不得不进行数十个服务间的调用。同时因为使用了分布式，数据的一致性、服务的可用性等重要指标得不到保证，拖累了整个开发组，最终拖死了这个项目。朋友说起这个事唏嘘不已，本来这个项目按部就班还是有希望做出一些成绩的。
从这个案例中，管理层低估了微服务开发的复杂性，甚至就是为了“赶时髦”。没有考虑团队是否准备好了，能否从容对一些不确定因素。巨人大哥一直坚信微服务不是面对初创项目和三五个人的技术团队的，初创项目缺乏用户量，用微服务就是大材小用，更多的精力应该放在业务推广扩展上去。
2. 团队管理跟不上
某传统行业IT研发部门，相比较上面团队要大很多，业务也比较成熟。但是在落地微服务架构的前期也出现了问题，首先也存在业务界划分不清的问题，其次微服务的项目依赖管理混乱，没有一个集中式的依赖池，造成后期迭代经常出现兼容性问题。团队依然是“大兵团”作战，没有根据业务拆分成为服务小组，一些决策权也没有下沉，跟不上快速迭代的步子。项目越做越复杂，进度越来越慢，最终拖了业务的后腿。不过幸亏及时改正了上面的大部分问题，避免被拖入了生鲜电商微服务的“泥潭”。
3.. 技术负责人缺乏相关经验
今年某个生鲜电商项目邀请我做项目指导专家，说要上微服务，希望我可以参与进来，但是从谈话中感觉他对微服务的理解仅仅是把服务拆开的一个层面，这让我感到不安，最终就没有应邀，不清楚现状如何。
巨人大哥认为一个要做微服务的团队由没有微服务经验的人来领导，那么结果只会流于表面，仅仅是使用了一些微服务的解决方案，潜在的各种性能问题、扩展性问题、可用性问题都没有洞察到。架构是服务于业务的，架构是需要实践的，架构是演进而来的，不能单单只学了几个框架，看了几篇文章，就信心满满搞微服务。这个一定是失败的，尤其是做生鲜电商这块，很容易误入歧途.
4. 什么时候该用微服务？
巨人大哥认为应该有以下几个条件的时候再考虑微服务：
1.一个最要的指标就是业务体量规模达到一个量级，或者业务目标非常明确，已经可以预计未来的规模，而当前的架构即将成为瓶颈时再考虑微服务；
2. 当前的团队技术实力，业务拆分能力出众，公司具备微服务实施的开发环境，具有科学的管理流程时先在一些边缘业务试试水评估一下，然后再做决定，
像谷歌、阿里巴巴这样一线的互联网大厂毕竟还是少数，盲目照搬，并不符合客观规律，最终为之所困。
要记住架构服务于业务，微服务不是银弹，不要为了微服务而微服务。
5 复盘与总结.
总结：
做微服务生鲜电商互联网应用，无论是生鲜小程序还是APP，都是非常重要的，本文只是起一个抛砖引玉的作用，
希望用生鲜小程序的微服务系统架构实战经验告诉大家一些实际的项目经验，希望对大家有用.
QQ:137071249
共同学习QQ群：793305035