您的位置:402cc永利手机版 > 互联网动态 > 微服务架构施行,怎么着连忙纯熟业务和项目

微服务架构施行,怎么着连忙纯熟业务和项目

2019-09-23 01:13

原标题:加入新公司,怎样快速熟悉业务和项目?

微服务并不是单独存在的,为了更好地实现微服务架构,需要整合许多组件混搭使用,方能打通任督二脉,天下无敌。网上很多大拿讲了微服务治理的内容,也有人单方面讲微服务的,比如spring boot与docker,本文着重于组件选型的较量,也积累了我们团队多次PK的精华;这些组件包括spring boot、spring cloud、docker、服务注册发现、RESTFUL、postman、jenkins、ELK、ETCD等。

很多新人进入一家新公司后,最头疼的就是如何快速了解公司的业务和项目架构,或者说不要求快速,即便有足够的时间,也很难在庞大的业务中整理出思绪。当然,如果你碰到一个特别热心的老员工,事无巨细地给你讲,随时在你身边答疑解惑,那可能还好。

背景

但很可惜,我没有碰到这样的人,在加入新公司后,带我的人几乎没花时间给我讲项目,也没给我安排可以熟悉项目的任务。

随着公司一年多的成长,我们已经开发了数十个项目了,后台有JAVA的有PHP的,为了更好地提升开发与管理效率,各技术大牛小牛们时常进行激烈的PK,碰撞出了许许多多爱的火花,比如其中之一:微服务实践

就这样的一个多月时间里,我慢慢靠自己的力量熟悉了大概十个项目,并在过程中总结了一些方法,借此机会记录一下,分享给大家。

设计

首先在这里强调一点,我的策略不是快速了解一个项目的具体业务,因为这个不同项目也不一样,无法总结。我的策略是大体了解整个业务线上的所有项目,大概摸清楚每个项目都是干嘛的,它们之间的关系如何,以便以后不论具体负责哪个项目都不至于找不到方向。

图片 1

这样等到需要负责具体到细节的业务时,虽然依然需要花时间,但相比整体一头雾水地开始,还是简单许多的。

微服务开发架构.png

一、必要条件

只需要有一套BASE微服务,BASE微服务生成业务系统微服务实例,供各个业务系统调用;业务系统不直接调用BASE,只能调用微服务INSTANCE。

我们首先要想的是,有了哪些必要条件后,给你足够的时间,你才能够完全了解整个项目?

问题一:有些人会问,假如有20个业务系统,那就有上百个微服务,这怎么管理得了?

这里说的必要条件不是“项目面对的客户是谁”、“项目用的框架是什么”这种,而是真真正正的必要条件,就好比用几条数学公理能推出整个数学体系一样。这里我总结的真正的必要条件只有两点:

这是运维的问题,让运维去解决,运维使用工具,实际也不算困难,反正执行的都是脚本,不需要手工操作。

  • 源码位置(gitlab或svn);
  • 部署环境(dev/test/online);

问题二:为什么不做成一个saas的微服务,这样就只有不到10个的微服务,就非常容易管理了不是吗?

所谓项目,其实就是一堆代码放在了一堆机器上而已,所以这些就足够了。

单点故障影响全局,我们选择了稳定更重要;另外saas的话,为了应对不同行业,会存在过度设计的嫌疑;私有化更容易。

当然,为了更加节约时间,最好还要有wiki、jenkins、页面访问路径、数据库地址。

调用逻辑

我之所以说那两个是必要条件,是想说其实项目本质上就是这么简单的一个事,你千万不要想的太复杂。它的业务可以无限复杂,但它的本质却逃不出这些,你千万不可以糊涂。当你无从下手或者什么都不清楚的时候,就主要把源码和环境弄清楚吧,其它的都是附属品。

图片 2

二、从页面到数据库的线

调用逻辑.png

有了上面的必要条件后,我们就开始了解项目了。由于不只是一个项目,所以千万不能深入具体代码,否则你就越来越烦直到放弃,也不会有好的效果。

  • 客户端调用业务系统,不直接调用微服务;
  • 微服务内部也存在调用关系。

对某个具体项目的了解,一定要建立在对整体了解的基础上。这时我们首先为各个项目画出一条线,并标明每一个节点的信息,就像下面的样子:

设计理念

页面访问路径——前端项目——后台服务——数据库地址

  1. 模块化是基础

这里的一个前端项目可能对应多个后台服务,所以最终的图应该差不多是这样:

非模块化,谈不上微服务,比如我们上面的用户微服务、产品微服务、地址微服务等,都需要先模块化,为了更好地落实开发,你可能不得不,边模块化边微服务,模块化的时候要注意,不能有关联查询,包要完全独立,到时候微服务才能拆开。

图片 3

图片 4

这个整理的过程,主要是让自己梳理清楚,一共有哪些项目,哪些是前端可视的,哪些是后台提供服务的,并且大致了解前端项目分别调用了哪些后台服务。通过后台服务和数据库的名称,我们能从本质上了解到这条业务线提供了什么功能;从前端项目和页面路径,我们能了解到我们需要给用户展示什么。

边模块化边微服务.png

注意,这个阶段我们只是见名知意,即使点开页面,连接上数据库看看,也千万别花过多的时间,因为这个阶段的重点就是仅仅知道这条业务线提的整体内容。

  • 松耦合、强内聚

在此基础之上,这个图可以不断细化,比如项目部署的机器,我们可以标注在项目旁边,或者保存在Xshell里。此外所有非业务相关的,能查到的尽量都记录下来。这个真的为以后找各种东西提供太多方便了。如果不在这一步这样做,别看你现在节约了时间,但等到以后查找相关东西的时候,时间加起来将会是天文数字了。

松耦合表示我们模块之间不直接依赖,无状态,可以单独地为外界提供服务;

这里关于整理项目部署的机器还有个小插曲,跟大家分享一下。

强内聚是指,我们虽然要拆分成一个个小的微服务,但是也要考虑某些功能的强关联性,比如一个凳子是由四个脚与一个板组成,我们不能把四个脚与板分开售卖,就没有意义了。

由于这部分的信息没人会一个一个地告诉你,就算有也不可能说的特别全。所以我是借助jenkins来整理的。项目部署都需要用到jenkins,只要查看jenkins配置的命令,就可以把部署环境一一整理出来,这个我认为是最全而且最新的。

开发

不要和我说查wiki,如果公司wiki都写的这么全,我估计就没这篇文章什么事了。当时我的jenkins权限特别少,只能看一部分项目,而且还只能执行,不能看配置,带我的人也是抠门,每次问他都给我开通所需要的项目的执行权限,多一点都不给。后来我也懒得问了,由于jenkins机器大家都可以用root权限登陆,所以我进入jenkins的配置文件config.xml,给我自己添加了一个admin权限,重启jenkins,再打开之后屏幕满满的项目都出来了,而且都可以查看和修改,畅通无阻。我就这样通过一个个jenkins的配置,整理了部署的机器,也看了下启动的逻辑。

  • 强大而友好的spring体系

三、了解项目间的关系

java开发5年以上的都非常清楚,很多JAVA框架都淡出了视野,比如hibernate、struts1、struts2,唯有spring越来越受欢迎。

这部分如果有老员工愿意和你说说,那最好还是了解一下。如果没有也没关系,先跳过这段,以后慢慢了解也是可以的。

spring-boot:较springmvc更加简约了,springmvc有一大零的配置文件,比如spring-servlet、spring-mybatis、spring.xml与web.xml,这些在spring-boot都不需要了,只需要强大的注解功能即可,boot更合适微服务。

四、整理数据库表

spring-cloud:里面有比较多组件,用于支持微服务,比如spring cloud config统一配置中心,用于多环境的配置文件配置,大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了;spring cloud eureka用于服务注册与发现,下面有单独介绍;其它的组件大家可以去官网看看,这里不一一介绍,总之如果JAVA平台,尽量使用spring体系的内容。

我们上面都是整理项目的大体框架,还没有涉及到具体的项目细节。这一部分,仍然不去涉及。

  • 数据库

如果说站在整个业务的本质上看,业务无非就是一堆代码运行在一堆机器上;那么站在单个项目来看,一个项目无非就是对数据库的增删改查操作而已;或者从使用者的角度看,一个项目就是输入一些参数得到一些返回结果而已。

我们采用mysql,因为我们是应用多,但数据量单表并不算大,多则不超过百万,mongodb也实验过,开发非常快,也非常灵活,但因为不是关系型数据库,维护成本较高。

所以接下来我们要做两件事:一个是整理数据库表,一个是整理Controller层的所有接口。

  • 权限认证
  • 找核心项目:这里首先要选择一个核心项目去看,众多项目中一定有一个是核心项目,就先从这个开始看起。
  • 筛选核心数据表:如果数据库的表比较少,那我们拿工具导出来表结构,一个个看就行了,这个不难。但如果数据库表特别多,我们首先要将表名全部导出,筛选出那些核心的表。这里导出表名、筛选表以及后面的分析表字段,不妨给自己做个工具,我在遇到一些很麻烦的或者感觉以后还可以通用的事情时,就会做成一个小工具,放在一个我给自己起名为javamate的程序中,这些小工具逐渐积累起来你会发现今后有意想不到的方便。
  • 判断哪些是核心表:不要着急,我们首先排除掉一些没用的。拿我在公司分析的系统来说,一共150多个表,其中有好多copy结尾的是备份,flow结尾的是流水,rel结尾的是中间关联表,statistics结尾的是数据统计表,log结尾的是日志表,config结尾的是配置表,等等。排除掉这些对核心业务理解无影响的表之后,所剩的也就20来张表,再根据它们的名字,可以看出好多表是属于一类的,比如order表就有各种order,按类别再分出来也就四五类,再分析起来就不难了。当然如果是更大的体系结构,那就要再不断做拆解。
  • 找出表之间的关系:在具体分析这些核心表字段之前,还要做一件事就是找出表中间的关系。如果表b中有个字段,比如叫a.id,那么b和a就是一对多的关系;如果两个表有rel中间表,那二者就是多对多的关系,起码从逻辑上讲是这样的。这个分析过程我也是做了个小工具,通过程序来判断的。

针对外部校验,内部完全信任机制。

到此,你就对整体的数据库结构有所了解了。根据表名也能对表的大致内容有所了解,接下来就是针对具体的表,看里面具体的字段和前人给出的备注,这个过程就没有技巧了,要耐心,要慢慢熬。

图片 5

五、整理Controller层接口

权限认证.png

当对数据库表做了以上的了解后,你基本上对这个系统能提供什么服务了解得差不多了。这个时候不论你的代码长什么样子,数据库摆在那里,能提供的服务差不多就已经出来了,对有经验的人来讲,代码的业务逻辑也大致能猜到个八九分。

  • 接口规范

我们梳理了大后方,那接下来就是把最前端和别人交互的部分搞清楚,这样掐头去尾,整个项目就解剖的差不多了。

RESTFUL:URL的资源与操作解耦,让URL更加符合语义,上百个接口也非常好管理,网上有很多文章讲得非常透彻,这玩意不是特别好理解,要多领悟,在项目中实践,就有矛塞盾开的感觉,这里不做详细介绍。

本文由402cc永利手机版发布于互联网动态,转载请注明出处:微服务架构施行,怎么着连忙纯熟业务和项目

关键词: www.402.com 402cc永利手机版