传统企业就应该这样进行微服务化

  很多传统企业看着互联网公司都进行着微服务化,因此也想享受微服务化带来的好处便对自己的系统进行改造,但微服务化 多“微”才是最优?有哪些拆分的原则?

架构原则

  • 使用成熟的技术,不需要最先进最好的技术,要是自己人能够掌控的,不然出现莫名的问题,一两天都可能解决不了,你就等着被拿来“祭天”吧。
  • 至少有一个冗余的实例,可水平扩展,确保一个实用多个负载,挂掉一个仍然能够正常运行,这里就要保证服务应用的无状态性。
  • 确保数据中心能在地理上隔离,实现异地多活容灾,实现三城两地式物理布署,即使一个城市停电仍可提供数据的正常访问。
  • 有一套发布回滚机制,确保发布异常时能回滚到上一个版本,同时可追踪到异常。
  • 在架构设计之初就构建监控平台,无监控无疑相当于系统在裸奔,后面扩容无数据支撑、BUG查找,异常追踪都无从淡起。
  • 不断小试错,而不是像传统项目开发周期达一年,在时间就是生命的时代,产品上线黄花菜都凉了。
  • 任务自动化,机器能够做就让程序自动跑,减少人力运维。
  • 实现故障隔离,自动保护机制,防止一个服务拖垮整个系统平台,进行健壮性分析。
  • ……

  所有的设计都是为了高可用,易扩展、高并发下出现异常更容易恢复,降低异常对业务的影响,这就是微服务架构设计的理念,但不完全,有些还是依靠架构师的经验结合自己公司的业务特点来思考,并不是适合所有的公司,传统公司进行微服务化的困难很大,但做得好收益也非常高。

做好业务的拆、合

  微服务讲究的是小 ,一个程序只做好一件事就够了,因此需要对原有臃肿的系统拆分,对零散的功能进行合。

一个业务场景一个服务

  如用户服务、授权服务、菜单服务、订单服务…… 这样的粒度好处是更新用户服务其它的服务可以不用更新。

一个数据库对应一个服务

  数据库操作层封装成一个服务,所有对这个数据库的请求都要经过这个服务,而不用知道这个数据库的密码,而且可以进行流量权限等进行控制。

一个接口一个服务

  这种架构很极端,会造成微服务数量成几何数增长,维护难度极大。

  适当的粒度优势是服务能够独离部署,扩展方便,耦合度较小。

  应用层我们可以结合上面的方法从下往上分析,对所有服务抽像化后抽出基础功能封成服务,这样公共服务就行成了,而且可以互相引用。

  这样就形成了基础服务,是一些基础组件,与具体的业务无关。比如:短信服务、邮件服务。这里的服务最容易摘出来做微服务,也是我们第一优先级分离出来的服务。

  还有些是业务服务,是一些垂直的业务系统,只处理单一的业务类型如:风控系统、积分系统、合同系统。这类服务职责比较单一,根据业务情况来选择是否迁移,比如:如果突然有需求对积分系统进行大优化,我们就趁机将积分系统进行改造,是我们的第二优先级分离出来的服务。   前端服务,一般为服务的接入或者输出服务,比如网站的前端服务、app 的服务接口这类,这是我们第三优先级分离出来的服务。   组合服务,组合服务就是涉及到了具体的业务,比如网购过程,需要调用很多垂直的业务服务,这类的服务我们一般放到最后再进行微服务化架构来改造,因为这类服务最为复杂,除非涉及到大的业务逻辑变更,我们是不会轻易进行迁移。

独立数据库

  数据层都是独立的数据库,即一个数据库对应一个服务,这里需要对数据库层进行纵向切分,即原来一个表现在对应多个表分片保存。

给数据库带来的挑战

  每个微服务都有自己独立的数据库,那么后台管理的联合查询怎么处理?

有如下三种处理方案:

  • 严格按照微服务的划分来做,微服务相互独立,各微服务数据库也独立,后台需要展示数据时,调用各微服务的接口来获取对应的数据,再进行数据处理后展示出来,这是标准的用法,也是最麻烦的用法。
  • 将业务相关的表放到一个库中,将业务无关的表严格按照微服务模式来拆分,这样既可以使用微服务,也避免了数据库各种切换导致后台统计难以实现,是一个折中的方案。
  • 数据库严格按照微服务的要求来切分,以满足业务高并发,实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中,在同步的过程中进行数据清洗,用来满足后台业务系统的使用,推荐使用 Mongodb、Hbase 等。

拆分过后落地架构

  • 在确定使用Spring Boot / Cloud 这套技术栈进行微服务改造之前,请先梳理平台的服务,对不同的服务进行分类,以确认演化的节奏。
  • 先让团队熟悉 Spring Boot 技术,并且优先在基础服务上进行技术改造,推动改动后的项目投产上线。
  • 当团队熟悉 Spring Boot 之后,再推进使用 Spring Cloud 对原有的项目进行改造。
  • 在进行微服务改造过程中,优先应用于新业务系统,前期可以只是少量的项目进行了微服务化改造,随着大家对技术的熟悉度增加,可以加快加大微服务改造的范围。
  • 传统项目和微服务项目共存是一个很常见的情况,除非公司业务有大的变化,前期不建议直接迁移核心项目,先搭建一个微服务架构,然后先接入新业务,后面再将老项目逐个改造,这里有个问题就是统一配置,统一规则,如日志,接口,文档,代码风格,公共类库 版本等等提前规范。

  以上只是个拆分建议,传统项目到微服务转化首先是思想上的转变就是很困难的,然后有些方法也不能套大公司的,只能是趋向大原则,根据自己的业务量,人力 时间等来改造。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券