微服务开发模式和传统的开发模式对比

2017-10-21 21:37:06 济南网站建设 12

使用微服务有一段时间了,这种开发模式和传统的开发模式对比,有很大的不同。

  • 分工不同,以前我们可能是一个一个模块,现在可能是一人一个系统。

  • 架构不同,服务的拆分是一个技术含量很高的问题,拆分是否合理对以后发展影响巨大。

  • 部署方式不同,如果还像以前一样部署估计累死了,自动化运维不可不上。

  • 容灾不同,好的微服务可以隔离故障避免服务整体down掉,坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。


给数据库带来的挑战

每个微服务都有自己独立的数据库,那么后台管理的联合查询怎么处理?这应该是大家会普遍遇到的一个问题,有三种处理方案。

1)严格按照微服务的划分来做,微服务相互独立,各微服务数据库也独立,后台需要展示数据时,调用各微服务的接口来获取对应的数据,再进行数据处理后展示出来,这是标准的用法,也是最麻烦的用法。

2) 将业务高度相关的表放到一个库中,将业务关系不是很紧密的表严格按照微服务模式来拆分,这样既可以使用微服务,也避免了数据库分散导致后台系统统计功能难以实现,是一个折中的方案。

3)数据库严格按照微服务的要求来切分,以满足业务高并发,实时或者准实时将各微服务数据库数据同步到NoSQL数据库中,在同步的过程中进行数据清洗,用来满足后台业务系统的使用,推荐使用MongoDB、HBase等。

三种方案在不同的公司我都使用过,第一种方案适合业务较为简单的小公司;第二种方案,适合在原有系统之上,慢慢演化为微服务架构的公司;第三种适合大型高并发的互联网公司。


微服务的经验和建议

1、建议尽量不要使用Jsp,页面开发推荐使用Thymeleaf。Web项目建议独立部署Tomcat,不要使用内嵌的Tomcat,内嵌Tomcat部署Jsp项目会偶现龟速访问的情况。

2、服务编排是个好东西,主要的作用是减少项目中的相互依赖。比如现在有项目a调用项目b,项目b调用项目c...一直到h,是一个调用链,那么项目上线的时候需要先更新最底层的h再更新g...更新c更新b最后是更新项目a。这只是这一个调用链,在复杂的业务中有非常多的调用,如果要记住每一个调用链对开发运维人员来说就是灾难。

有这样一个好办法可以尽量的减少项目的相互依赖,就是服务编排,一个核心的业务处理项目,负责和各个微服务打交道。比如之前是a调用b,b掉用c,c调用d,现在统一在一个核心项目W中来处理,W服务使用a的时候去调用b,使用b的时候W去调用c,举个例子:在第三方支付业务中,有一个核心支付项目是服务编排,负责处理支付的业务逻辑,W项目使用商户信息的时候就去调用“商户系统”,需要校验设备的时候就去调用“终端系统”,需要风控的时候就调用“风控系统”,各个项目需要的依赖参数都由W来做主控。以后项目部署的时候,只需要最后启动服务编排项目即可。

3、不要为了追求技术而追求技术,确定进行微服务架构改造之前,需要考虑以下几方面的因素:
1)团队的技术人员是否已经具备相关技术基础。
2)公司业务是否适合进行微服务化改造,并不是所有的平台都适合进行微服务化改造,比如:传统行业有很多复杂垂直的业务系统。
3)Spring Cloud生态的技术有很多,并不是每一种技术方案都需要用上,适合自己的才是最好的。