微服务与敏捷开发（Scrum/Kanban）的核心思想之我见
关于“微服务”和“敏捷开发”的文章网络上有很多，所以这里不再重复叙述这些概念的解释和特点，而是就个人实际工作中对他们的核心思想的理解及运用分享给大家，希望能对大家有所帮助。
当下IT开发领域，“微服务”及“敏捷开发”越来越被各公司及团队重视。但是在交流中发现很多人对“微服务”及“敏捷开发”存在很大的误解，尤其在各公司的招聘岗位介绍中更能看到很多描述错位的地方。
首先，微服务和敏捷开发都是指导思想，是模式和方法，并不是特指某个软件应用、开发语言、开发框架等。并不是使用了某个软件应用或某个框架就算是微服务或敏捷开发了，也不是采用微服务和敏捷开发理论指导开发工作，就必须要使用某些软件或开发框架才能进行，这个是对微服务和敏捷开发的严重误解。
其次，在实际开发工作中，这两个指导思想要紧密的联合起来运用，才能达到更高效的团队运作，才能既快又好的进行产品迭代，将这两种指导思想的优势充分发挥出来。
先说一下微服务
微服务是一个架构理念，是指导架构设计的一种思想模式，延伸了领域驱动设计（DDD）。微服务是为解决逐渐复杂的系统设计、开发问题而提出的。当一个应用系统太过复杂时，设计与开发难度要比简单功能的系统大得多。其主要原因就是系统内有太多的耦合。这对系统迭代可能是致命的。DDD理论则较好的解决了这个问题，所以微服务把它作为了业务划分（微服务模块）的重要指导性理论依据。
微服务是将一个完整的系统分割成若干微小的、具备独立性的功能单元，每个功能单元是可以具备一个实际意义的小功能集。各个功能单元之间尽量是解耦或松耦合，可以实现独立开发而不依赖其他功能单元，自成一个微小的服务应用。这个开发理念与N年前流行的模块化开发是异曲同工，也可以说是模块化开发模式的延伸。但是微服务强调的是每个微服务模块可以独立工作在自己的环境或进程中，当然也可以与其他服务工作在同一个环境中（这里也许有人说这样你就不是微服务了，这也是误解之一，继续看！）。
为什么要将一个系统拆分成若干独立的微小服务呢，优势在于：
1、每个微小服务都可以由独立的团队或成员开发，不一定非要统一开发语言，可以各自发挥团队、小组、成员的开发优势。
2、每个微小服务都可以部署到一个独立的环境中，他们之间通过轻量级的通信机制进行交互，如果一个服务出现问题，不会造成整个系统瘫痪。
3、可以让系统阶段性上线，提前上线重点功能，使产品面世时间提前。
4、单个服务代码量相对很少，出现BUG影响的范围相对小很多，可以快速定位BUG的位置。
5、更易于扩展功能，不会因为增加新的功能而改动整个应用或分析整个应用的代码，只需要增加微服务模块就可以实现了。
6、各个微服务模块功能单一，这样结构十分清晰，使系统开发的复杂性大大降低，框架流程都很容易理解。
7、有新技术应用可以在后续的模块中直接使用，不用考虑之前已完成的服务。
综上所述，微服务在开发时，理论上是可以各自为政的，只要完成预定的功能就可以了。这与以前常用的单体架构的一动则动全身相比，优势十分明显。
要达到微服务这个效果，核心是架构负责人能有效的把整个系统拆分成微服务模块，能真正做到微服务模块之间相互解耦。必需耦合的服务能做到尽量松耦合，否则后面的任何工作都不能顺利进行。若架构没有理顺，使用再多的微服务工具也是无济于事的。微服务的工具链是辅助微服务模式落地的工具，不是必需的。前提是架构要合理，工具才能发挥作用，如果把两个深度耦合的服务分别放在两个容器（如Docker）中，那么这一系列微服务的意义就不存在了。
如果做的微服务架构合理，即使暂时没有容器的部署环境，那在开发、发布、迭代过程中仍然有巨大的优势。仅仅是各微服务模块没有在独立环境中运行，要在部署和维护时考虑环境的影响而已，其他特点还是具备的。
微服务架构设计的着重点：
1、业务功能尽量单一，每个微服务模块只实现一个单一的业务逻辑，不要将可拆分的多个业务逻辑写在一个微服务模块中。比如会员注册模块，只需要处理会员注册的业务逻辑，其他的不要考虑进来。
2、通信要足够轻量，模块使用中，通信传输的内容要尽量做到足够轻量，序列化消耗要尽量做到最小，否则会给整个系统带来很大的运行压力。要在一个系统中有统一标准，可以跨语言、跨平台使用。使每个微服务模块有足够的独立性。
3、接口定义要具前瞻性，在一个系统应用中，总会有些模块无法彻底独立运行，需要另外的模块配合才可以得到正确的结果。这种情况在设计接口的时候，要充分考虑可能存在的修改，尽量减少对相关其他微服务模块的影响。
4、模块充分独立自治，可以把一个模块看做一个小应用项目。开发、测试、运维都可以独立进行，数据库也是独立的，它就是一个完整的应用。
5、模块划分依据业务领域，而不是技术领域，也就是在该业务领域看是不是属于一个独立的服务模块，而不是从技术角度看是否适合作为独立的模块。
微服务也不是处处完美，也有它的弊端：
无论当前的系统复杂与否、庞大与否，都需要复杂的分布式部署。这同时也给运维带来了复杂性，维护量大大增加，对运维团队要求提高很多。在测试阶段，也会引入更复杂的问题。很多微服务模块运行环境是一样的，也会带来大量的重复部署，代码块无法跨服务共用，多个微服务模块中同样的代码要重复劳动。
再说一下敏捷开发
敏捷开发是以微服务架构为基础，以人为核心，指导我们化繁为简、迭代、循环渐进的一种高效开发的方法。也就是把一个大项目根据业务结构和市场需求，拆分成多个小项目，并评估好开发优先级，然后依据优先级或市场调整逐一开发、测试、集成、部署运行。在这个过程当中，大项目已上线的部分一直是处于可运行的状态。敏捷开发具备快速上线、响应市场需求的商业价值。
敏捷开发强调的是敏捷，是每次迭代的轻量、高效，而不是一味的追求快速，更不是越快越好。因此它是依据良好的微服务架构设计，良好的项目应用市场需求顺序评估，合理的人员分配及高效的沟通方式，与需求方的密切合作及快速响应变化等最终达到理想的效果。
深入理解一下敏捷宣言中的敏捷软件开发的四个核心价值：
@个体和互动高于流程和工具：这里强调了人与人直接沟通的重要性和高效性，所以有站立会议的说法。但不要理解为完全不需要流程和工具，只是侧重人与人的沟通。
@工作的软件高于详尽的文档：这里强调的是把更多的时间放在开发软件上。但不是说文档就一点也不要写了，关键性的文档（项目整理流程描述及架构图等）还是要有的。
@客户合作高于合同谈判：这个要区别公司属性，外包公司团队和企业自有项目团队肯定会采取不同的策略。这句话应该是讲给企业自有项目团队的，为了企业合作双方的利益，这个观点是正确的。但不是说毫无底限的向客户妥协，而是提倡密切合作可以提前发现问题，双方都可以减少损失，实现共赢。
@响应变化高于遵循计划：这句道出了软件开发不可回避的问题，就是需求变更。站在企业整体利益的角度，需求变化是很正常的。随着市场变化、时间推移，之前的需求如果不做修改可能真的就影响了产品的落地效果。但这也不是说就可以任意的变来变去，肯定也是需要有既懂业务又懂技术的人来负责全面评估，才能决定是否修改。
Scrum（冲刺）是实现敏捷开发的具体方式之一，是一种具体实施方案和流程，也称之为管理框架。基本流程如下：
1、首先确定角色：敏捷大师Scrum Master（主要负责消除障碍，带领团队运作，敏捷教练，服务型领导）；产品负责人Product Owner（主要负责描绘产品愿景，定义优先级）；开发团队Scrum Team（主要负责实现产品）。
2、工作任务拆分，将项目拆分出一个可以阶段性完成的小任务，制定待办事项计划表，评估优先级，时间周期的拆分，开计划会议讨论确认。
3、细化更小的任务，人员细分。
4、每日站立会议，汇报昨天完成了什么，承诺今天完成什么，提出遇到的问题，并更新燃尽图。
5、每日集成、编译、测试，反馈结果。
6、一个小任务全部完成，演示会议，评审，产品负责人及客户必须参加，通过则上线发布。
7、最后开总结会议，针对刚完成的小任务开发过程中遇到的问题和好的方法进行讨论，需要改进的地方应用到下一个小任务当中。
Kanban（看板）是敏捷开发的另一种具体实现方式。看板的原则是“一件出去，一件进来”，由WIP（正在进行中的制品）驱动，每个人的工作都是以制品方式在看板上标注，上下游关系十分清楚。所以看板团队多久能把手头上的事情做完就是他们的响应时间。看板图对应的是流程，不一定只有一个团队。看板模式没有明确的任务时间，以任务完成为准，所以看板上会看到有1一个月完成的，也有3天完成的。
看板模式重点是通过制品驱动，及时发现问题，然后调整团队解决问题。通过这种方式解决整个团队的瓶颈，达到高效的目的。
实际应用敏捷开发中，Scrum和kanban两种思想要综合起来运用才会更好的体现敏捷开发的优势。在Scrum模式中，是把所有人都相对理想化了。但是规定的时间不一定100%都能完成，如果融合kanban模式，就可以适当调整成员（或调动资源协助），达到进度均衡的目的，才能更有效的保障小任务的预算周期。
通过上面的简单介绍，大家可以看到这里涉及到一个现在很热门的几个词“持续集成、持续部署、持续交付”，因为一个项目被拆分了若干小项目。逐步完成逐步发布的，那么势必需要“持续集成、持续部署、持续交付”来支撑。这样也就带来的实际操作中过于复杂的问题。因此就有了很多支撑微服务/敏捷开发的工具链（如：Active Collab、Jira、GitHub、Gitlab、Jenkins、CodeShip、JUnit、CircleCi、Bamboo、PagerDuty、DynaTrace、Docker、Kubernetes(k8s)、SpringCloud等等），帮助简化整个过程的复杂程度和实现难度。但是工具链的掌握和应用也是一个新的成本。
个人建议
最后说一个仅代表我个人的观点的建议，不是所有的公司都适合使用或全套使用微服务及敏捷开发的。在团队人数不多、项目还在创业初期的话，是不适合全部采用微服务及敏捷开发的，可以按照微服务的理念做架构设计，但是上线不一定要各自独立运行，这样将大大减少你的技术投入成本。如果就十几人的团队，敏捷与否真的差别不大，把这套思想的精华运用到管理中就可以了。至于整套工具链的运用，反而会给您带来更多的压力。
如果项目创业初期就开始全套引入这些思想模式，可能没等成员都适应这些模式，项目已经被对手先拿下了。