微服务的优缺点及实践反思

最早接触微服务系统来自当时我们当时技术主管LR，
当时使用的dubbo-zookeeper，
不过这套现在不经常用了，大多数公司使用Spring Cloud，
而初次接触Spring Cloud是我们当时信息管理系统的更替优化时，
当时注册中心还是使用的Eureka，
而当初最早接触关于微服务的书是翟永超写的，

离职期间，去图书馆泡了下，又翻看了Spring Cloud，
微服务优点，肯定的，不然要什么微服务？

no1 松耦合，这里的这个松耦合我感觉其实稍微有点片面，
在微服务里进行服务间调用，通过feign是可以不关心接口的实现，
但是归类到松耦合我感觉有点不太妥当，其实这个也对应其一个缺点
也就是缺点里的no1不稳定，
服务间调用，不管是加重试机制还是其他，都不能很好的体现出原本
单体服务直接本地调用方法的感觉。

这里我感觉解决的方式就暴力点：
举个例子，用于要获取某个特殊的TOKEN，
而一般验证权限的相关接口定义在auth模块中，
而真正获取用户信息等相关，比如用户列表，用户更改密码等
在user模块里，而获取这个TOKEN，可能之前代码
是通过auth里一个接口然后远程调用user获取用户信息加密成TOKEN返回。
这个解决就是两个分支，
一个就是直接在user里加这个TOKEN接口省去远程调用，
一个就是直接在auth模块里查user等表，（这个书里也是有提到的）
不过第二种方法必须是有一些的微服务模块使用的同一个数据库连接，
不然是无法达到预期效果的。

no2 抽象
说的其实就是上面提到的不同模块使用不同的数据库连接，
对单一模块单一的管理数据库以及对应的数据库表，
比如电商系统里，用户表在数据库189.32.0.23:3306/taohuo-user
而订单呢可能在数据库123.97.0.29:3306/taohuo-order
这样的优势显而易见，打个比分，
订单超级多，订单服务挂了，访问不了0.29，
而用户登陆时其实不受影响，
这个用户登陆后，可以查看自己的优惠券，但是看不到自己订单了，
比如用户登陆只是想改个密码，则不会受到影响，
因为用户服务依旧running，0.23也依旧没问题。

如果合到一起，就可能，比如，
有个程序员迷之自信，自己使用了刚了解不久的组件，
并且说服了技术经理，技术经理感觉一般也没啥问题，
然后上线了，结果订单达到某个峰值，组件性能是有问题的，
产生死锁等相关问题，服务挂掉，数据库挂掉，甚至订单产生了脏数据。
这也不仅要一一排查，而且这个期间用户是登陆不了这个系统的。

同样这里也显现出缺点no2
即微服务的事务问题，
暂且不说服务模块是否用一个数据库连接，
有些业务比如下单，
下单扣除用户的优惠券，
扣除库存，
库存中的商品信息，
支付扣款，
可能涉及到不同的如订单模块，用户模块，优惠券模块，库存模块，商品模块，支付模块。
这样下来，就算使用如RocketMQ这样的异步可支持事务的组件来处理全局的事务，
谁能保证这些服务都能达到全部高可用呢。
我看到有些商场系统里很好地解决这一点，
他们把service进行分层，即有service模块，有controller模块，common......
不过这样就丢失了微服务的意义，即服务间的解耦，
而且这样做是无法再去横向扩展的，
单纯地只是从代码结构分层上，显得不那么臃肿罢了。

让我们，继续，
看下微服务的优点no3和缺点no3
同样如上，书上举例的缺点no3也是订单，
比如订单得和用户去有所关联，使用了什么优惠券，有所关联，
订单详情里，订单里是啥商品，（可能是商品快照，没有直接和商品关联）
比如订单要调用库存，查看库存是否足够，等等。
虽然我们把用户啊，订单啊，通用common啊，甚至相关middlewire啊，
都做了分层分包，
但是如缺点no3讲的全能对象，到底该如何是好呢？

其实我构思了下，是不是可以通过构建一个business层，
将订单与人员相关的，订单与库存相关的，订单与优惠券的业务，
统统塞进去，而这个模块负责将这相关联的业务模块进行统一的
依赖管理。继而，在对应业务调用服务时，通过远程调用也好，
通过依赖服务也好，使用business中的管理方法来完成业务。
同样的，business可实现横向扩展，这样也就实现了负载。

但是同样这样也伴随着在business中虽然事务得到了更好管控，以及去掉了
远程调用带来的可能的非高可用，但是同样的business模块如果涉及到更多业务，
可能变得比较繁杂，但如果保证只是涉及到不同模块中的事务的业务使用business，
其他不涉及的不使用，还是可以的。
而同样business自身要进行负载，保证自身的高可用。

那么接着优点no4
面对现代互联网公司竞争激烈，以及用户需求的多样性和变化性，
敏捷开发大行其道，在微服务中，相关的需求实现，可能是在不同的微服务模块中的，
这样的话，不同的人员对各自需求实现有掌控，
不同的需求对应不同的人员开发的不同的模块，
在更迭开发部署时也更加灵活。

对于缺点的后两条，
不做过多评论。

总之，微服务就是这样让人又爱又恨地开发方式。