精益微服务工作坊系列目录
- 精益与微服务的关系：微服务理念、精益理念。工作坊的演示练习案例
- 微服务搭建秀，现场演示微服务框架：Java的Spring Boot、Docker、等
- 微服务测试驱动开发：微服务的验证测试。测试金字塔的缺失与改良
- 微服务接口开发与测试：契约测试以及集成。集成联调的灵活配置
- 微服务的DevOps：微服务底下的DevOps就是微DevOps
- 探讨微服务的质量属性：系统通常的质量属性在微服务下如何达成
- 微服务的实施：如何有效的落地微服务。遗留系统多又复杂怎么办
第一期 - 精益与微服务的关系，微服务搭建秀
由黄药师和雪峰发起的精益微服务工作坊系列上周日在 Thoughtworks 北京办公室交付了第一期成果，总共有20多个来自不同领域和公司的小伙伴参与到我们的活动中来，“汉”会议室都有点hold不住了。在这里对本次活动做一个回顾和总结，梳理一下整个活动主线和精彩片段，对尾声部分的反馈和精彩的讨论进行一下整理和汇总，以便更充分地去准备下一期的内容。
先来几张全景暖暖场
标题必须高大上
雪峰在哪里？
黄博士在沉思
饿了的举个手
这个问题怎么这么难搞？
ICE Breaking
满满的套路啊，我们的活动属于workshop，这一步当然是要的了，每个小伙伴自我介绍，规则是介绍自己姓名爱好之前需要讲出你前面两位介绍者的姓名和爱好（原本是想全部串联，难度还是有点大，后面的小伙伴得累的半死啊），机（ji）智（zei）的小伙伴就有开始打小抄的了，我想说这是赤果果的作弊啊，下次要规定不准动手，只能动嘴。说到动情处都有好几个小伙伴直接就是“爱雪峰的旅行的爱看书的我”都出来了，基情四射啊。这就是这个环节精彩的地方，打破不熟悉的僵局，让大家迅速嗨起来，快速投入到后面的干货分享和实战中来。
装备破冰
考虑到大家带来的吃瓜工具型号，品牌差异比较大，我们的实战中用到的工具和环境又相对比较新，所以已经给大家准备好了vagrant 虚拟环境和项目文件，文件比较大5G多。原本是想通过airdrop互相传一下，结果因为各种原因折腾了比较长的时间，后期我们可以通过提前将环境通过云端分享给大家，这样就可以来之前就可以将环境搭建好了。
Thoughtworks 安利
此处省略1w字，请移步Thoughtworks
实战环境说明
我们的所有服务和依赖已经打包到虚拟机镜像中，用vagrant加载后就可以run了
- vagrant + virtualbox 构建我们的虚拟机环境
- spring boot 框架实现我们的微服务
- gitlab-ce 搭建git仓库托管我们的代码和配置
- jenkins 2 pipeline 作为CI服务
- docker + docker compose + nginx + shell 作为简化版本的CD
- shell 脚本实现红蓝部署
精益和微服务
微服务已经烂大街了，有不良的方法也有好的方式，那我们如何区分好坏呢？答案是精益思想，软件交付的改进目标就是缩短开发和交付的周期和节奏，并可以以持续的方式获得更好更快的反馈。
你心目中的精益代表什么？
淘宝买家秀，祝贺黄博士瘦身成功！
精益的根本是什么？
实战场景
背景
史密斯，team lead，负责实施某医院集团的产品，接触到Bahmni，希望采纳它们的SaaS医疗平台，此外还希望实现医疗服务的预约功能，他希望在精益快速稳定的基础上完成业务目标。
期望: 快速稳定的交付
在还没有考虑具体需求时，我们先要确保快速稳定的交付能力，如何做？我们需要什么样的工具链和方法论来来构建这样的快速交付能力？
- 自动化测试 （没有自动化测试，你怎么对的起QA妹妹）
- 持续集成 （没有CI，只有梦想，代码是没法自己变成可工作的软件）
- 持续交付（交付部署点两下就可以去喝咖啡了，so easy）
- 微服务（自我治理，高度模块化开发部署）
微服务是啥？
Martin Fouler 与 James Lewis 共同提出了微服务的概念定义：
- 微服务是以单一应用程序构成的小服务
- 自己拥有自己的进程和轻量化处理，服务依赖业务功能设计
- 全自动的方式部署
- 与其他服务使用HTTPs协议通讯
- 同时服务会使用最小规模的管理能力（例如 Docker）
- 服务可以用不同的编程语言和数据库来构建
一个微服务一般具有一下特征：
- 服务独立性，自治性
- 单一职责
- 自我包含（自给自足）
- 高度解耦
- 高度弹性
- 具体实现不可知
- 并行可扩展并具有弹性
- 定义良好的接口
- 单个团队端到端的所有权
单体架构和微服务架构的区别
微服务的利与弊
任何一个事物都有正反两面，微服务也不例外
利
- 强烈的模块划分
- 独立部署
- 技术多样性
- ...
弊
- 分布式
- 最终一致性
- 运行复杂度
- ...
分布式计算的谬误
基本上每个人，当他们构建分布式应用时，都会做出以下八个假设，所有这些假设最后都证明是假的，从长远来看，都造成了你痛苦和黑暗的经历，都是过来人，谁还没点痛苦的经历呢，但是自己做的假设，爬也要爬到终点（自己拉的狗屎就得自己收拾）。
- 网络可靠 （每天都有抽风的时候）
- 延迟为零 （开什么玩笑，我一个大招还没放出去，人已经挂了）
- 带宽是无限的 （土豪也没用）
- 网络是安全的 （总有人在伺机而动）
- 拓扑不会变化 （世界说变就变）
- 有一个管理员 （自己从头干到尾，哪有什么管理员）
- 运输成本为零
- 网络是同质的
史密斯的练习之路
讨论和反馈
经过一整天的学习和操练，小伙伴们已经有点扛不住了，打住打住，大家开始讨论了，说说自己的感受，以及对活动的反馈。以下整理了讨论中比较集中的一些问题和简短的回复。
- 对于老旧遗留系统如何切入并做到微服务落地？
这个有点难。 - SOA vs MicroService
其实微服务才是对SOA的最好的诠释，厂商所谓的SOA就是在给你下套，绑定你，持续薅羊毛。 - 微服务的指导原则是什么？
后期会有专题。 - 好的REST API设计规范是怎样的？
可以参见amazon和微软的设计准则。 - 想推进微服务，如何说服团队接受并开始采纳？
我们公司现在敏捷咨询不会再去谈敏捷和老的方法论的区别，直接开整，为什么？因为只有客户他们意识到并理解了敏捷才需要专家来做咨询，需要时间，但好的东东值得等待。get到要点了吗？ - 现有团队能力和学习曲线陡峭如何克服？
世界上最苦逼的什么职业？（小伙伴回答：程序员，程序员），有人拿枪逼着你做程序员吗？没有吧，那你为什么要做？学习是一辈子的事情，这是基本能力。没有这个就不要想其他的了。 - 微服务拆分是否意味着后期团队的组织结构划分？
微服务只是一种架构上的设计方法，并不会导致组织结构划分。 - 如何合理去界定微服务的边界？
这就要用到DDD，还有Event Storming方法论了，基于业务。 - 微服务对ops团队带来的挑战如何克服？
简单粗暴，把他们拉下水，当他们看到有rancher，docker，jenkens，ELK这样的好东东在辅佐他时，他就会着迷。
致谢
本次活动由我们Thoughtworks同事黄药师（黄博士）、吴大师（雪峰）发起，美女同事张婷，海侠全程支持，还有我们几个小伙伴现场协助，请大家期待后续大招......
