电商重构之微服务架构初体验（一）

之所以写这篇文章是因为公司的电商项目技术项目性能已经跟不上，项目结构也有着极大的问题，是个单体项目结构一个war包打天下，聚集了各种功能以及资源全都在一个工程里面，而且前后端不分离还是用的jsp，更新迭代也很麻烦，更新一个管理后台都要导致整个项目需要重启，用户端也会无法打开，启动也很慢，要高达五分钟。业务模块不明确，鱼龙混杂整个项目直接看上去无从下手，接手时候简直想 *****。随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的水平不一),会让你每次提交代码  ，修改每一个小bug都是心惊胆战的基本上每次能动前端我都不会改后端去重新部署项目，生怕一个小问题，全体宕机无法用。所以要解决一些现在存在的问题以及让这个项目更长远的运行，就有了这篇文章。但是不得不说SSM前后端不分离，迁移到springboot，目前对我来说是就是灾难性的，也希望大佬看到不足和有问题之处及时伸出援手救救满头黑发的孩子。

什么是微服务

微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务。

比如现在我们项目的有订单、商品、支付、库存、会员等模块，如果没有根据业务模型来拆分为订单服务、商品服务、支付服务、库存服务、会员服务，像之前我们搞了抽奖活动定金可退，十几天累积了2万多笔订单，这些订单还需要退款，当我执行批量退款的时候，导致系统内存溢出，直接整个服务宕机打不开，像这样的活动又不多，我不可能再去部署一台专门退款，没办法就夜里12点开始退款，商城挂上系统维护中的页面。虽然解决了问题但不是最好的办法，如果拆分了之后退款是一个单独的服务，即便退款卡住了，整个系统核心功能例如下订单，访问，支付还是可以使用的，大概看起来就像下图。

那么看看目前我们项目现在的架构

单机架构

简单暴力，不知道以前是怎么想的pc和mobile这两个模块的接口基本上是一模一样的唯一的区别就是jsp不一样，我真的是吐了每次修改项目都得修改两个地方，两个要一起发布，经常出现改了A忘了B的情况加上人员紧张力不从心啊，经常会出现各种各样的小问题,而且是前后端不分离,提交文件胆战心惊的,一般能不动就不动,除非大的模块修改。如果并发的增加扩展也是纵向扩展

单机架构扩展

现在每次做电商活动，时间紧任务多，根本就不可能在现有的项目上迭代开发，目前是搭建了一个新的项目叫active,每次都在这个模块迭代开发活动， 但是遇到一些和商城项目有关联的业务逻辑还是要动一下，我基本上是本着能不动就不动的原则，但是例如这种下单即可抽奖，下单抽取半价车等活动，基于订单的基础，所以没办法还是要在原来的项目上进行迭代交互。一个是war包，一个是jar包，部署的算是环境吧，也不一致，一个单独运行一个放在tomcat里面运行，而且我一直懒得搞活动项目的高可用等等一些东西，一直都是让他裸奔，不行就多跑几。因为之前特殊情况，举办了一个下单抢口罩的活动，项目直接雪山式崩塌服务器资源直接爆满，整个项目全程宕机，做了一个很LOW的方法那就是直接限流，反正都是凭借运气，抢不到也不怪我了。其实更重要的是还出现了一个致命的问题就是Sql在本人能力之内极大优化之下，还出现了准确性的问题。活动持续了两周每天就是看着什么时候能抢完，当天把服务关了。每次活动持续时间也不长，就人工凑合凑合就过去了。还有一个致命的问题就是每次出现问题排查困难，那个日志啊，简直就是老太太穿棉袄一套又一套。

微服务架构

 

微服务架构

微服务扩展可以对某个模块单独扩展，例如订单服务压力过大，我就可以单独添加订单的机器，像之前如果有问题，需要重新从头到尾的部署一套新的环境出来，现在都是用的docker部署方便了很多，当然后面微服务架构部署也是个麻烦事情，如果没有运维还是要自己学习一下，这里推荐k8s+docker+jenkis，这也是微服务的一个缺点吧，毕竟有利有弊还没有百分百完美的事情

概念

①:将一个单一应用程序开发为一组小型服务

②:每个服务运行在自己的进程中

③:服务之间通过轻量级的通信机制(http rest api)

④:每个服务都能够独立的部署

⑤:每个服务甚至可以拥有自己的数据库

微服务以及微服务架构的是二个完全不同的概念，微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把 一个一个的微服务组合管理起来，对外提供一套完整的服务。

 

微服务的优缺点

优点:

①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码 需要了解整个系统)

②: 开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了）

③: 微服务能够被2-5个人的小团队开发，提高效率

④: 按需伸缩

⑤: 前后段分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参

⑥:一个服务可用拥有自己的数据库。也可以多个服务连接同一个数据库.

缺点:

①:增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war包 (k8s+docker+jenkis )

②:服务之间相互调用，增加通信成本

③:数据一致性问题(分布式事物问题)

④:系能监控等,问题定位..........................

 

适用场景

合适

①:大型复杂的项目............(来自单体架构200W行代码的恐惧)

②:快速迭代的项目............(来自一天一版的恐惧)

③:并发高的项目................(考虑弹性伸缩扩容的恐惧)

不合适

①:业务稳定，就是修修bug  ，改改数据

②:迭代周期长发版频率一二个月一次.