步骤1:以终为始,先构建一个独立的敏捷微服务团队
管理建议:
-
让微服务团队完全脱离之前的工作,专心于微服务的工作中。如果分心同时做几件事,每件事都不会做到最好。
-
给微服务团队一些特权,为了满足“全功能微服务团队的”诉求,特事特办。
-
如果团队在执行的过程出现了依赖,进而阻碍了进度。则需要把依赖标明出来。代码中的依赖容易看见,但组织中的流程依赖很难发现。
-
为了避免团队对外部的“依赖惯性”,让团队自己想办法在内部解决依赖。
-
组织流程的改变也是很重要的微服务架构产物,而不仅仅是微服务代码或基础设施。
技术建议:
-
为微服务建立一个全新的代码库,而不要从原先的代码库上克隆或者复制,避免和原团队的开发依赖。
-
建设一个独立的持续交付流水线,最好是通过“流水线即代码技术”(例如Jenkinsfile)来自动生成流水线。
步骤2:构建微服务的“电梯演讲”
-
(XX微服务)用来
-
在(出现痛点的场景)的情况下
-
解决(解决现有的某个问题)
-
从而(达到什么样的效果)
-
提升(微服务的价值)
-
(订单查询微服务)用来
-
在(订单查询数量快速)的情况下
-
解决(访问数量迅速升高导致整体应用性能下降的问题)
-
从而(分离了订单查询请求)
-
提升(其他功能的性能)
管理建议:
-
把微服务的电梯演讲打印出来挂到墙上,让团队成员铭记于心。这会强化组织对微服务的边界认识。
-
随着团队的反思和学习,电梯演讲有可能会变更,但一定要让团队形成共识和一致的意见。
-
不要期望一次就能划分正确。划分是一个持续权衡取舍的过程。
技术建议:
-
明确了微服务的职责和边界之后再去看代码,否则会被代码的复杂度影响。
-
领域驱动设计(DDD)可以帮助你更好的划分微服务。领域驱动设计很好的遵循了“关注点分离”(Separation of concerns,SOC)的原则,提出了更成熟、清晰的分层架构。
-
不会领域驱动设计(DDD)也没有关系。简单的使用“关注点分离原则”也可以帮你达到这一点。例如:从接口中分离出流量较大的接口独立部署,把读数据库和写数据库的API分开独立部署,把静态和动态访问分离……
步骤3:以最小的代价发布出第一个微服务
-
级别/职责分工明确的组织沟通结构。
-
“长时间,慢反馈”的行动习惯。
-
先进且学习成本较高的技术栈。
-
最精简的独立敏捷全功能团队。
-
最快的时间。
-
代价最小的技术栈。
管理建议:
-
尽量让现有微服务团队自己学习解决问题,成为全功能团队。如无必要,绝不增添新的人手。
-
“扯破嗓子不如甩开膀子”,先动起来,在前进中解决问题。
-
先考虑最后如何发布,根据发布流程倒推。
技术建议:
-
根据当前技术采用的情况选择代价较小的技术栈。
-
采用动态特性开关(Feature Toggle),在发布后可以在生产环境动态的控制微服务的启用,降低失败风险。
-
如果采用了特性开关,一定要设立删除特性开关和对应旧代码的时间,一般不超过两个月。否则后面大量的特性开关会带来管理成本的提升和代码的凌乱。
-
由于团队比较小,功能比较单一,不建议采用分支来构建微服务,而应该采用单主干方式开发。
步骤4:取得快速胜利(Quick wins),演示(Showcase)驱动开发
-
构造第一条微服务流水线。
-
上线第一个微服务HelloWorld
-
构造出第一个微服务自动化测试。
-
构造出微服务DevOps平台。
-
完成整个产品的微服务架构拆分。
-
构造微服务自动化运维体系。
管理建议:
-
要防止团队画大饼,完成好每日和每周的工作目标即可。微服务开发本身就没有很长周期。
-
强迫团队有所产出,这样才能用关键产出驱动开发。产出不一定是代码或者基础设施,一篇总结,或者学习的文章分享,甚至是踩过的坑和遇到的问题都可以展示,目的是要打造自治学习的团队。
-
贵在坚持,不要计划太远。超过一个月,就要对目标是不是范围过大进行反思。
-
以天为单位拆分任务,超过一天的必须要拆分。无法在一天完成的工作需要拆分出阶段性产出。
-
如果能结对,并且能够每天交换结对,showcase不必要。
-
可视化所有任务,用敏捷看板来管理任务是了解现状的最好方式。
技术建议:
-
想办法让第一个微服务尽快发布到生产环境,生产是最重要的。
-
完成了HelloWord的发布,就要考虑如何对发布流程进行改进。而不是着急准备下一个业务上线。
步骤5:代码未动,DevOps先行
-
持续交付流水线。
-
微服务运行平台。
-
要让Dev和Ops共同参与决策、设计、实现和维护。
-
团队完全独立自主,打破对现有流程的依赖。
-
不断的追求改进,让团队形成改进的团队文化。
管理建议:
-
“新程序快速投入生产”能给团队继续前进最大的动力。
-
如果你的组织是Dev和Ops分离的组织,先咨询一下Ops工程师的意见。最好是能够给微服务团队里面配备一名Ops工程师。
-
如果不具备实施DevOps的条件,微服务架构就要从运维侧,而不是开发侧开始进行。
技术建议:
-
微服务的平台一开始可以很简单,以后慢慢增强和扩展。但是一定要部署到生产环境里使用。
-
如果想使用现成的微服务平台,可以参考Spring Cloud。
-
微服务运行平台可以通过灰度发布技术在生产环境并行运行。
-
采用灰度发布技术在生产环境中逐步提升微服务的使用占比。
-
基础设施即代码是DevOps核心实践,可以帮助开发人员迅速在本机构建生产环境相似的开发环境,减少环境的不一致性。可以采用Docker,Ansible,Vagrant等工具来完成。
-
基础设施对微服务应该是透明的。微服务不应该也没必要知道运行环境的细节。只要能够正常启动并执行业务就完成了它的任务。因此,基础设施代码要和微服务业务代码分开,且微服务不应该告诉平台自己如何部署。
-
服务注册和发现是微服务架构的核心部分。consul和Eureka是这方面的佼佼者。
-
部署(Deploy)和发布(Release)要分开。
步骤6:除了提交代码和发布,微服务平台一切都应当自动化
-
自动化功能性测试(UI/集成/单元/回归)
-
自动化构建
-
自动化部署
-
自动化性能测试
-
自动化安全扫描
管理建议:
-
团队成员自发的进行自动化的改进,这会给未来微服务批量开发带来很多益处。
-
不要一开始就追求全面的自动化,自动化需要花费一定时间。根据团队的进度视情况适度进行。
技术建议:
-
采用TDD的方式开发不光可以提升质量,也完成了测试的自动化。
-
契约测试可以解耦微服务提供者和消费者的开发。但是要注意始终保持契约的有效性,一定要先改契约后开发。
-
注意自动化的安全隐患。机密信息需要独立管理,例如可以采用 Hashicorp Vault 这样的服务。
-
关键步骤需要准备自动、手动两种方式,必要时可以干预自动过程。
-
采用git的hook技术,在代码push之前就可以完成测试和静态检查,提升CI的成功率。
步骤7:总结并复制成功经验,建立起微服务交付的节奏
-
微服务开发到发布的端到端流程规范。
-
微服务开发的技术质量规范。
-
团队合作中坚持的最佳实践。
-
常见技术问题总结。
管理建议:
-
刚开始的时候可以每周举行一个回顾会议,团队需要快速的反馈和调整。
-
不要急于扩张团队,要在成功经验稳定并形成模式之后再快速扩充。
-
避免微服务良好的开发氛围被稀释,刚开始的时候扩充团队可以慢一点。新老成员的配比不要超过1:1。
-
虽然微服务平台趋于稳定,但在微服务没有上规模之前,不要让团队里缺少Ops成员。
-
注意知识的传递和人员的培养。
技术建议:
-
不要急于在微服务应用规模不大的时候形成微服务模板,这会限制未来微服务的开发和扩展。
-
在微服务不成规模的时候不要放松对微服务平台和交付流程的改进。要做到最快的时间交付和发布微服务。