专栏首页james大数据架构传统企业就应该这样进行微服务化

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

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

架构原则

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

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

做好业务的拆、合

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

一个业务场景一个服务

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

一个数据库对应一个服务

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

一个接口一个服务

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

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

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

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

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

独立数据库

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

给数据库带来的挑战

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

有如下三种处理方案:

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

拆分过后落地架构

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

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 架构师必须要知道的阿里的中台战略与微服务

      传统企业平台都是烟囱式的系统架构,企业内部为了迎合业务发展不停的打造各种系统,导致各系统间的重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力,财力...

    欢醉
  • 用SpringCloud进行微服务架构演进

      在《架构师必须要知道的阿里的中台战略与微服务》 中已经阐明选择SpringCloud进行微服务架构实现中台战略,因此下面介绍SpringCloud的一些内容...

    欢醉
  • android之数据存储之SQLite

              SQLite开源轻量级数据库,支持92-SQL标准,主要用于嵌入式系统,只占几百K系统资源此外,SQLite 不支持一些标准的 SQL 功能...

    欢醉
  • 成功微服务实施的技术演进微服务演进的技术背景通过度量驱动架构的微服务化

    在上一篇文章《我们如何衡量一个微服务实施的成功》里,我们介绍了衡量一个微服务改造成功的七个特征,分别是:

    顾宇
  • 微服务架构实施原理详解

    基于微服务架构和Docker容器技术的PaaS云平台建设目标是给我们的开发人员提供一套服务快速开发、部署、运维管理、持续开发、持续集成的流程。

    好好学java
  • 保护微服务架构的10个有效方式

    微服务是一种创新的方式来加速和改进软件开发。该术语是指可以单独开发的应用程序子组件,并且通常专注于一个特定功能。例如,用于在线购物的电子商务应用需要具备订单收集...

    SDNLAB
  • 请不要在“微服务”的狂热中迷失自我!

    2017年是“微服务”疯狂的一年,如同股灾前的狂欢,各种不同行业的技术团队都在宣讲着自己微服务实践的道路。然而大家是否有反思过自己真的在玩“微服务”吗?您真的在...

    程序猿DD
  • 企业应用云计算减少成本需要注意哪些问题?

    很多企业和组织都聚集到云中,因为对云计算报有很高期望,通过降低投资成本、运营支出的可预测,还能提高可扩展性,使CIO的管理工作变得更加简单。关于云计算市场中基础...

    静一
  • 微服务与SOA架构(2)

    服务分类学 服务分类学指的是在某种架构下服务是如何归类的。有两种服务分类的基本类型:服务类型和业务领域。服务类型分类法会根据整个架构中服务所扮演的角色进行分类。...

    首席架构师智库
  • DevOps能力是落地微服务的前提

    在软件开发领域不存在银弹,当用一项新的技术或新的架构时一定要明白其背后的原理,确保把合适的技术应用在合适的项目上,而不是盲目跟风。 单体应用伸缩性差,而且随着应...

    静一

扫码关注云+社区

领取腾讯云代金券