大哥你玩微服务,玩它有啥用啊
5243
2018-07-24 13:12    文章来源:吕建伟 阿朱说
文章摘要:从我个人工作经历经验来看,我是没看出来微服务能让那个个性化定制开发更好。

这篇文章应朋友需求,刚才花了半个小时写完了。估计有许多错别字或语句不通畅处,由于我时间安排紧张,请大家海涵,大家理解个大概意思就行了。

有问题解决问题。

一开始,我并不明白什么是微服务,虽然我是从CORBA、COM+、J2EE、WebService、SOA、SpringCloud一路上来的。

(1)性能

一开始,只是把大的代码拆小了。

无他,就是因为大的代码性能太差了,成了大规模并发时的瓶颈点。把藕断丝连关联在一起的功能逻辑,拆成一块块专属功能,让主干主流程功能逻辑代码保持简洁,这样保证常用业务处理流程能很快处理完。过去认为这些代码都是藕断丝涟不能拆分,后来因为代码性能阻碍交易增长,没办法,拆吧,其他能想的招都想了,只能拆,所以硬着头皮拆了,后来发现硬着头皮拆也能拆,功能逻辑并没有那样血肉相连离了谁就要死。

后来,还是因为大规模并发性能,致使在大促活动的时候,把分支流程和功能都用开关关闭了,只保证常规主流程能快速通过就可以了。这也是当时进行微服务化拆模块带来的好处

(2)效率与质量

还是因为藕断丝连,所以修改的效率与质量总不平衡。往往是修改了A功能点,B功能点莫名其妙的也出异常了,仔细一分析B功能点,原来是形成暗的关联了,比如在前端Javacript层、JSP层、逻辑层、SQL层。

因为老出现这样的连带异常,所以每次修改之前,都要做不少代码走查的工作,看看哪些功能点代码之间关联性。在测试环节也是需要花大量的时间来测试关联性影响。这给研发效率带来很大的制约。如果中国互联网&电子商务要求迭代速度快来争取商业胜出,这样的研发效率就没法满足了。如果牺牲质量,不搞关联性代码排查分析、关联性功能点修改、关联性测试,那么质量就成了问题,照样影响交易完成。

所以,没办法,做个下列改造:

1、集成登录门户

2、主数据独立

3、ESB企业总线中间件

4、每个子系统或模块,独立的物理数据库

5、每个子系统或模块,独立的代码项目

6、统一的源代码库,CheckIn时自动触发代码检查。代码检查插件有专门的接口变更关联度检查,发现有关联接口发生变更,不允许签入

这样,各个子系统或模块之间,都代码和数据物理独立、接口明确、关联性明确。这样子迭代效率变更速度就快了,而且质量还能有底线保障。

如果你只是纯粹使用SpringCloud这种微服务框架,就像解决性能、效率、质量这个三角问题,没门。这就是很多研发人说,我也用了微服务啊,但是我的问题仍然没有解决啊。这就是问题的根。

(3)还想更研发效率高、质量高

有人说,我们也按你上述的方法做了,但是我还是觉得我们的研发效率需要再提高,应该怎么做呢?

我给大家几招:

1、组织变革:研发团队全职能化

过去是产品、开发、测试三个部门,现在按功能模块组成固定的正式的部门(而不是临时项目团队)。每个正式的功能单元部门,包含产品经理、UI设计、架构师与开发、测试四大岗位。每个正式的功能单元部门,7-20人,不能超过20人,不能少于7人,高于20人要强制拆分、低于7人要取消团队合并进其他团队。如果这个功能单元偏向业务应用型,就让产品经理做Leader,如果这个功能单元偏向基础技术型,就让架构师做Leader。另外,不要单独提出架构师独立岗位,架构师在国内被妖魔化了,所以为了踏实工作,让高级或资深程序员担当架构设计职能就行。

为啥这样分工呢?第一,产品开发测试都在一个固定长期部门了,大家过去是利益和KPI不一致的,现在利益一致、心向一致、目标一致、KPI一致,坐在同一个工位区了,沟通也及时了顺畅了,所以效率快了许多,传递失真导致的Bug也少多了。

另外,我过去也认为不少功能点之间存在逻辑关联性。后来把团队强制转型成全职能部门了,发现功能点关联性大为减少。就是因为各个部门内敛封闭了,各个部门之间老死不相往来了,信息不通畅了,非必要性接口就自然减少了。原来啊,很多所谓的功能逻辑关联,都是我们自己意淫的啊,都是我们一堆人坐在一起你一言我一语添加意见累积上去的。

现在,除非是必要的业务流程打通,否则的话,各个部门之间都不需要沟通接口。即使是需要接口,也都是遵照统一的接口规范,统一接到SOA中间件网关那里,而非像过去几个人一勾兑你开放我调用那样谁也不知道。

至于说大家担心的各岗位专业提升问题,大家可大不必担心。打仗是最好识别人才、历练人才、给人才上位机会的场景。

有仗打仗,没有仗我们故意造仗,比如说过去根本没有618、双11,我们故意造出来。

而且,也只有类似618、双11这样的大仗,才能倒逼性能要求、研发效率。没有高性能要求,研发团队就会逐步改进、小修小补改进,根本不会大动代码、剥离代码成微服务。

2、自动化:灰度发布、DevOps、容器化、APM自动化运维

这四个技术机制也能保证开发环境、生产环境一致,不会出现在开发时候还好好的,在生产环境就出问题,或者生产环境出了问题在开发环境就是重现不了。

另外,灰度发布,也让代码问题影响面不会一下子扩大。小范围发布,有了问题赶快在线诊断、在线热补丁修改,或者赶快回滚

3、过程管理:隔日发布、每日例会、数据说话

今天修改、明天发布、后天修改、大后天发布。所以每次的修改都是很小范围的,即使出了问题也立刻就知道了是昨天的修改出现问题了,所以查找定位分析问题、快速修补问题,其效率、质量、成本都很不错。

每日例会,是让每天的进展,整个团队都信息同步,内部各岗位协同的问题,大家也都知道,和其他部门的协同问题,大家也都知道。

数据说话,尤其是业务运营人员和产品经理,都统一拿业绩KPI指标说话,都统一拿系统中出的数据说话,而不是各说各利益、各有各的数据来源。

4、统一代码

所有代码,按功能模块分成不同的代码项目,但都在同一个代码平台上,受统一的代码版本管理、统一的代码审核插件运行、统一的DevOps。

而且,全研发体系人员,都能看到别的功能单元的代码、文档,知道别人在干什么,知道别人的代码写的怎么样、实现程度怎么样。

但是,每个功能单元部门,只能CheckOut和CheckIn自己的项目代码,不能CheckOut和CheckIn其他部门的代码。这样就保证了既共享又独立。我们经常遇到的错误,就是Copy其他团队代码改改,又改的不干净,导致出现各种莫名其妙问题或者关联问题,这样的关联问题真不应该出,原本就不是关联的嘛,只是Copy别人代码剔除代码时不了解别人的代码剔除的不干净造成的假关联嘛

(4)微服务能让个性化定制开发更好吗

我过去写过两篇文章:

1、《SaaS到底可不可以定制开发

2、《你知道PaaS平台的P有多少种写法?

大家先看完这两篇文章,有了PaaS平台,也清楚了到底啥叫定制开发,咱们再返回头来看看微服务能让个性化定制开发变的更好。

从我个人工作经历经验来看,我是没看出来微服务能让那个个性化定制开发更好。有过这方面成功经验的朋友们,你们可以留言说说。


版权声明:

凡本网内容请注明来源:T媒体(http://www.cniteyes.com)”的所有原创作品,版权均属于易信视界(北京)信息科技有限公司所有,未经本网书面授权,不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的,应在授权范围内使用,并按双方协议注明作品来源。违反上述声明者,易信视界(北京)信息科技有限公司将追究其相关法律责任。

评论