微服务[开发生命周期]

在个体层面，开发者需要熟悉每一个微服务，即便它可能非常小，为了开发一个微服务，开发者会使用很多相同的技术框架和技术：Web应用框架、SQL数据库、单元测试、类库等等，这些都是开发者在开发应用程序时经常会用到的
在系统层面，选择微服务框架会对开发者设计和运行应用的方式产生重要的影响，主要在3个维度：服务设计、服务部署、服务监控

在微服务开发周期的这三大迭代阶段中，每个阶段所做出的合理决定都有助于构建出具备可恢复性的应用，即便面对不断变化的需求和不断增加的复杂度，应用仍然具备可恢复性

根据这三个阶段思考用微服务交付应用所要采取的措施和步骤

微服务设计

在开发微服务应用时，开发者需要做出一些设计决策，这些设计决策在开发单体应用时并不会遇到，开发单体应用时，通常会遵循一些已知的模式或者框架，比如MVC，但是微服务的设计需要考虑的是如下几个问题：

是从一个单体应用起步，还是一开始就是用微服务
- 单体先行的出发点在于，在开发的前期，开发者还没有了解系统中各个组件的边界，很难定义服务边界，但在微服务中定义边界出问题，可能代价很大，应该先单体先行
- 微服务先行的出发点在于，一开始开发速度会慢一些，但是能够降低未来开发的冲突和风险，系统后期的开发速度反而非常可观
应用的整体架构以及开放给外部消费者的接口
如何识别和划定服务边界
- 为每个服务选择恰当水平的职责(功能范围)，例如如果想对订单服务进行扩展，引入一个新的特殊订单类型，开发方案大致3种：1、对现有的服务接口进行扩展2、添加一个新的接口3、添加一个新的服务，每个方案各有优缺点，同时也会影响到应用中各个服务之间的内聚和耦合

服务之间如何通信，同步还是异步
- 服务之间的通信虽然同步的通信更易于排查问题，但异步系统的解耦性更高，能够降低变更风险，还能让系统更易于恢复，但异步系统复杂度更高
- 在微服务应用中，开发者需要在同步和异步消息之间进行平衡，从而有效地对多个服务的行为进行协调
如何实现服务的可恢复性
- 在分布式系统中，一个服务不能完全信任它的协作方服务，这并不一定因为代码糟糕或者人为因素，开发者不能想当然的认为服务之间的网络乃至这些服务的行为是可靠的，可预测的
- 服务在遇到故障的时候需要能够进行恢复，为了做到这一点，开发者需要通过在出现错误的时候进行回退，对于一些不友好的调用方要限制器请求速率，动态寻找健康服务等方式来使服务具有防御性

微服务部署

在构建微服务时，开发和运维是相互交织在一起的，在由大量的自治服务组成的系统中，如果这个服务是开发者开发的，就应该由开发者来运行它，对服务的运行方式了解充分，更有助于开发者在系统发展壮大以后做出更好的设计决策

应用的特别之处是它所交付的商业价值，而这来源于多个服务之间的协作，实际上，开发者可以将每个服务所提供的特有功能标准化和抽象化，以保证团队聚焦于商业价值

开发者应该达到一个阶段，也就是在部署新的服务时，不涉及任何客套的东西，为了快速创新，部署新服务的成本必须是可以忽略不计的，部署步骤标准化并在这些服务上保持一致，为了达到这个目的：首先需要将微服务部署的人为操作标准化，其次实现持续交付的流水线

可靠的部署是很单调的，其中不应该有事故发生，但太多的团队恰恰相反，软件部署成为一个压力很大的操作，而且病态地需要全员出动，一个服务如此，那么大量的服务可想而知

微服务部署的人为操作标准化

通常每一门语言和框架都有自己的部署工具，每一门语言自己的部署环境也很复杂多样

从技术角度来说，服务自治一个非常大的好处就是差异化，但是差异化并不会让服务部署变得容易，没有一致性开发者就无法把生产环境的服务部署方法标准化，进而会增加部署管理和引入新技术的成本，最差的一个结果就是每个团队重复造轮子，每个团队有自己与众不同的依赖管理、打包、部署和应用运维的方法

完成这项工作最好的工具就是容器，容器是一种操作系统层面的虚拟化方法，它支持在同一台主机上运行多个独立的系统，每个系统共享同一个内核，但都有自己的网络和进程空间，与大部分虚拟技术相比，容器的构建和启动速度都要快很多，能够在秒级完成，同一个机器上可以运行多个容器，这样不但可以简化本地开发的复杂度，而且能够有助于在云环境中优化资源利用率

容器将应用的打包过程、运行接口进行了标准化，并且为操作环境和代码提供了不可变的特性，这使得它们成了在更高层次进行组合的强有力的构件，通过使用容器，开发者可以定义任何服务的完整执行环境并将他们相互隔离

容器技术目前有很多，例如FreeBSD的jails和Solaris的zone，但最成熟和友好的工具还是Docker

实现持续交付流水线

持续交付是一种开发实践方式，通过这种实践方式，开发者可以在任何时间将软件可靠地发布到生产环境中

如图所示是一个简单的流水线，可以看出每个阶段都能够向开发团队反馈代码的正确性
微服务是持续交付的理想推动者，因为它体积小，可以快速开发并独立发布，为了持续交付软件，开发者需要注意以下两个目标：

制定一组软件必须通过的验证条件，在部署的每个环节，开发者都应该能够证明代码的正确性
代码从提交状态发布到生产环境上的流水线实现自动化

搭建一套可验证的、正确的部署流水线能够让开发者工作的更加安全、并和他们在服务开发阶段的迭代步调保持一致，在交付新功能时，这种流水线是一种可靠、可重复的流程，理想情况下，开发者应该将流水线重的验证条件和步骤标准化，并在多个服务间进行使用，这样能够进一步降低部署新服务的成本

持续交付还能降低风险，因为软件的质量和团队交付变更的敏捷性都能够得到提升，从产品的角度而言，这可能意味着开发者可以按照一种更精益的方式进行工作，即快速验证开发者的假设并进行迭代

微服务监控

微服务的透明和可观测也是非常重要的，在生产环境中开发者需要了解系统的运行情况，其重要性有两点：其一，开发者要主动发现系统中的薄弱环节并进行重构；其二，开发者需要了解系统的运行方式

和单体应用相比，在微服务应用中，完全监控是一件非常困难的事，因为一个事务可能会涉及多个不同的服务，在微服务中不同技术开发的服务可能会生成格式相反的数据，因为数据的总规模也要比单体应用高很多，如果开发者能够理解系统的运行方式并能够进行深入观测的话，即便微服务很复杂，开发者还是可以对系统进行高效的修改的

发现潜在的薄弱环节并进行重构

不论是引入程序错误、运行环境错误、网络发生故障、还是硬件出了问题，都会导致系统故障，久而久之消除这些未知的缺陷和错误的成本要高于快速和高效地响应所花费的成本

监控和报警系统使得开发者可以对问题进行诊断，并给出相对及时和准确的判断，开发者可以通过自动化的机制来响应这些警告，例如在其他服务器或者机房创建一个新的容器实例，或者增加服务器的运行实例数量来解决负载问题
为了将故障的影响最小化并避免在系统内产生连锁反应，开发者需要采用一些支持服务局部降级的方案来设计和调整服务间的依赖，即便一个服务不可用，也不能导致整个应用挂掉
承认故障总是会发生的并做相应的准备，这是非常重要的

了解数以百计的服务行为

为了了解这些服务的行为，开发者需要在设计和实现这些服务时，提高透明性的优先级，收集日志和数据指标，并将他们统一起来用于分析和告警，这样开发者在监控和分析系统的行为时，便可以诉诸于所构建的这个唯一的可信来源，从而精准判断

开发这可以标准化和抽象化每个服务提供的特有功能，如图所示，最中间是服务提供的特有业务功能，在这之外属于工具层，这些工具可以让业务功能更易于观测，开发者可以在这些层之间跟踪每个请求，之后将从每层收集的数据推送到一个运维数据库用来进行分析和监控

有责任感和运维意识的工程师文化

在考察微服务的技术性时，将其与开发这些微服务的团队割裂开，是一种错误的行为，通过一个个轻量的、独立的服务来构建应用会彻底地改变组织工程化的方式，因此对团队的文化和优先事项进行引导式微服务应用能够成功交付的重要因素

对于那些已经成功实现了微服务架构的组织来说，很难将原因和结果分清楚，到底是组织结构和表现成就了细粒度的服务开发模式，还是细粒度服务的开发经验成就了团队的结构和表现

长期运行的系统并不仅仅是设计和开发，然后把功能堆起来，它还反映了开发者和运维人员的偏好、观点和目标
“受到约束”表示沟通结构会限制和约束系统的开发效果，事实上，微服务的做法意味着它正好相反，其避免系统开发过程中的冲突和紧张，最重要的方式就是按照开发者要开发的系统的形式和状况来设计组织，有意识的和组织结构相互依赖实现共生，才是微服务的最佳实践

为了能够从微服务中获益并充分的管理其复杂度，开发者需要制定一些对微服务应用有效的工作原则和规范，而不是继续采用以前开发单体应用时所用的相同的技巧