目前很多互联网公司都采用微服务架构,微服务的优点和缺点被反复说到,这里不在重复赘述,只结合工作中的一些实践,说说要用微服务要注意的点,厚颜写做编程范式,其实就是一些具体实践而已。
原则是比较抽象的一个概念,简单说是一些指导意见,在不同的组之间可以共享,是为了实现一个共同的目的,必须准守的一些规则,或者叫做规矩。
这些规则(或规矩)对我们开发过程中有一定的约束作用,不容置疑,必须遵守。如果发现有那个团队或者个人没有准守,一定要及时纠正,否则,原则就没有任何存在的意义。
现在用的很广的一个原则是Heroku的 12-Factor 原则。具体内容如下:
I. 基准代码
一份基准代码,多份部署
II. 依赖
显式声明依赖关系
III. 配置
在环境中存储配置
IV. 后端服务
把后端服务当作附加资源
V. 构建,发布,运行
严格分离构建和运行
VI. 进程
以一个或多个无状态进程运行应用
VII. 端口绑定
通过端口绑定提供服务
VIII. 并发
通过进程模型进行扩展
IX. 易处理
快速启动和优雅终止可最大化健壮性
X. 开发环境与线上环境等价
尽可能的保持开发,预发布,线上环境相同
XI. 日志
把日志当作事件流
XII. 管理进程
后台管理任务当作一次性进程运行
在我们团队中有一些原则可以和大家分享:
标准的定义会比原则更加具体,有点类似于道和术、战略和战术的关系,不同的技术栈、不同的团队可能会制定不同的标准。
这些标准,最好形成文档,放在知识库中。这样,团队的成员可以随时查看,有新人加入时,也能避免老员工口口相传,传错了指令。
有些架构师认为,原则和标准就是一个东西。就我来看,这两个粒度不同,对于大的团队,最好分开。因为大的团队,技术栈更加多样化,标准没有办法做到一致,但是原则可以做到不会脱离大框。对于小的团队,因为技术栈比较单一,有可能就是一个技术栈(就像我现在的团队),因为标准只有一个,就是对原则的细化,所以两者就是一个东西。
标准的另外一个作用,就是告诉团队成员怎么做是对的,怎么做是更好的方案,更加直白的表述是,按照标准进行开发,bug更少。
有了开发标准之后,就需要将标准推广到所有人,但是每个人的理解力和执行力是有偏差的,所以需要一些手段来快速推广。具体的方法有:DEMO(示例)、代码模板(脚手架)。
软件开发是一个比较有技术壁垒的行业,一个新人(没有经验或者有经验刚加入新团队的人)想要快速了解老系统所使用的标准,是比较困难的,毕竟每家团队采用的标准都不是百分之百一致。比较简单的做法就是,提供新人DEMO示例,然后告诉他,“就照着这个做”。
对于有经验的新人,一定是先接受,然后在了解清楚之后,才会提出自己的一些看法,而不是一上来,就搬出自己以前的经验,全盘否定团队指定的标准。
代码模板的作用实现一个服务的集成方案,经过有效可靠的裁剪和定制。在需要新建服务时,就使用这个方案,直接进行业务代码开发即可,所以也被称为脚手架,比如SpringBoot的Starter和AutoConfiguration。
前面说过,我们团队使用的是Java技术栈,基于SpringCloud开发,所以我们对SpringCloud进行封装,定义了几根通用的组件,比如定义了一个 web-misc
组件,引入这个组件,就能够实现,引入实现WebMvc,并且提供了统一的获取Metric信息的接口,统一的异常处理的ExceptionHandler等。
虽然我们都是代码洁癖,但是有时候迫于时间压力、业务压力,我们不得不背负一些技术债务。
比如我们知道硬编码会破坏系统灵活性,但是明天就要上线,根本没有时间做配置型服务,所以只能硬编码到系统中,这就是技术债务。第二天系统上线,正常运行,如果这个时候把硬编码事情抛之脑后,这个债务就会产生利息,不知道哪天就会变成炸弹。
对于技术债务,我们团队的做法是做一个技术债务清单,设置超时提醒功能,限期修复。这个清单是公开的,每一项都注明了,是谁,因为什么,于什么时间,产生的技术债务,需要在什么时候修复。如果是临时特性或功能产生的债务,也需要注明特性或功能过期时间,由专人检查债务是否已经没有了。
个人主页: http://www.howardliu.cn
个人博文:微服务编程范式
CSDN主页: http://blog.csdn.net/liuxinghao
CSDN博文: 微服务编程范式