为啥我用了微服务架构,软件还是不好修改啊?

java架构大牛 · · 1939 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

很多人跟我说:老师,我也用了微服务中间件啊,为啥我的程序还这么复杂,这么不好阅读理解、不好修改、不好组合啊?

嗯嗯,问题其实很简单,只有约束规定,没有约束手段。所以我比较喜欢Golang或Ruby on Rails这样的工程语言,特别适合中国这些万金油、需要大规模堆人来作业的开发模式。

那应该怎么办呢?

我告诉大家一个方法,只有这样方法一起用,你的微服务才能真正成为微服务。总的思路其实就一条:要故意强制约束到小。

一、UI层

你一定要基于类似小程序的技术,而且一定要做在智能手机里。只有这样,你才会受约束。因为智能手机屏幕小,输出就少,因为智能手机没有键盘和鼠标,所以你输入也只能少。

咱们中国万金油程序员,不会开发程序,往往是界面上的功能多复杂,代码就多复杂。所以啊,让UI界面上通过强制约束倒逼它不能放太多功能,代码就就少多了。这是前提基础条件。

而且,最好是把类似小程序的技术,内嵌在类似IM(微信)这样的移动化协同门户里。过去咱们做功能模块,都有个集成门户,左边是层层叠叠的功能树,右边是各种指标图,复杂得就像驾驶飞机。现在好了,被内嵌进一个类似即时通信这样的软件平台里了,没有菜单树了。那怎么办啊?嘿嘿嘿,小程序写的功能,只能通过场景来触发弹出出现了。哪里还有有形的ERP体系,哈哈哈,都被场景打碎了。

不是功能复杂就是好产品。

二、逻辑层

UI层有:移动协同门户+小程序UI组件,那逻辑层也需要三个东西:Serverless + 分布式微服务中间件 +Docker 容器。

FaaS我是特别赞同的。很多人不会写函数,都没有经过函数设计编写的训练,如函数命名、隐藏性、函数输入输出参数设计、函数异常保护、函数日志、函数返回值,这都是需要精心设计的,需要天长日久训练的。我曾经见过1000多行的存储过程,谁都不敢动,很少有人能全看明白。

所以,通过Serverless这种函数编程,就把一个功能强制约束要做简单。

很多人问过我一个微服务到底要拆到多少粒度合适?我说,拆到你能掌控了的粒度就行了。拆的细了,是灵活了,但要修改的时候,可能需要十来个函数才能做到你想要的效果,忘修改一处,跑出来的结果就不是你预想的。这就很影响效率和质量,进而影响了成本。如果你把所有逻辑都一股脑放在一个函数里,还是太复杂,就和那个1000行的存储过程一样。所以,该拆多细的粒度,根据你这个万金油的能力来。要知道,大部分的程序员都是呈现正态分布的,天才和蠢货都挺少,大部分人都是中庸打酱油人,所以你觉得拆的差不多了,你能掌控的住,那说明大部分人都能掌控住。这种粒度就够了。

一定要有Docker。

Docker就意味着物理隔离(虽然也只是假物理隔离)。咱们过去写万金油软件,哪里需要对接,就调用一下。这样天长日久就形成了很多文档上没有记录的系统关联调用。如果用了Docker,嘿嘿嘿,都隔离了,你咋调去。就得强制让你不能调用,才被迫想到通过统一的SOA企业服务总线来调用。

Docker就意味着开发期环境和运行期环境一致,不会出现常见问题:生产系统说有问题,在测试环境就是重现不了。或者是,有人擅自改动了生产环境。

三、技术中台层

你一定要有主数据平台、API网关。

能通过主数据调用的就调用主数据,而不是直接调用另外一个业务系统的数据。你想调用其他业务系统的业务逻辑代码,你就必须要通过API网关来统一走,而不是直接就交叉调用了。

有了这两样东西,你的各个模块、各个业务子系统,都是简单依赖的

四、基础设施层

一定要用云服务器、云存储、云数据库、云中间件、云人工智能平台、云大数据平台、云IoT平台、云文档照片音频视频处理中间件。这些都是云化的、分布式的。这样你就不用写一个Serverless函数就打包一大堆依赖的底层中间件。你一个Serverless Docker里面就干干净净的只有你自己的应用模块代码。

你一定要用到DevOps、灰度发布、大规模日志监控运维、大规模全链路监控运维。这样,就不会有人为在过程中干涉,导致不同经验的人有不同的后果。

五、组织

组织也非常重要。

第一,组织要全职能组织,比如,一个团队,产品经理、UIUE工程师、架构师、前端开发工程师、后端业务逻辑代码开发工程师、测试工程师,在一个团队了,而不是干每个事情都需要产品部门、UI部门、开发部门、架构部门、测试部门来回地临时抽调人。临时抽调协同,干的活谁也没有责任,谁也不负责,谁都临时凑合。效率、质量都极差。

第二,组织大小要控制。一定要在7-20人之间。高于20人必须拆分。小于7人施展不开,大于20人,沟通成本协调成本都很大,而且最最导致的问题是:你因为人多,所以你会自然而然地把功能做的很复杂。所以故意给你人少,你干不了多少,所以这样也是强制约束你做不了太复杂太重型的功能。

不是人多就能出好产品。

六、过程

建议不要项目管理,不要超过1个月的项目。

最好的小步迭代是:当日内测版、每周铁杆粉丝版、每月公开版。这样的周期来发布软件。

千万别憋大招,一憋就容易把功能憋复杂了。

不是周期长就一定能出好产品。


有疑问加站长微信联系(非本文作者)

本文来自:简书

感谢作者:java架构大牛

查看原文:为啥我用了微服务架构,软件还是不好修改啊?

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

1939 次点击  ∙  1 赞  
加入收藏 微博
1 回复  |  直到 2019-05-01 17:13:36
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传