首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >传统企业就应该这样进行微服务化

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

作者头像
欢醉
发布2019-05-25 18:48:34
6320
发布2019-05-25 18:48:34
举报
文章被收录于专栏:james大数据架构james大数据架构

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

架构原则

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

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

做好业务的拆、合

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

一个业务场景一个服务

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

一个数据库对应一个服务

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

一个接口一个服务

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

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

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

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

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

独立数据库

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

给数据库带来的挑战

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

有如下三种处理方案:

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

拆分过后落地架构

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

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

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019-04-02 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 架构原则
  • 做好业务的拆、合
    • 一个业务场景一个服务
      • 一个数据库对应一个服务
        • 一个接口一个服务
        • 独立数据库
        • 给数据库带来的挑战
        • 拆分过后落地架构
        相关产品与服务
        数据库
        云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档