本文讲的是微服务和软件交付的4个原则【编者的话】本文介绍了使用微服务架构时需要考虑的问题和遵循的四个原则，对于从传统架构向微服务架构转型起到了很好的指导作用。
【上海站｜3天烧脑式微服务架构训练营】培训内容包括：DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。
微服务是一个杰出的架构，因为这种架构便于对软件系统进行管理。但实际情形是，有很多遗留的应用并没有采用微服务架构，也必须纳入统一的管理范畴。任何一个企业组织，尤其是大型组织机构，都不会使用单一的软件架构。
企业拥抱微服务架构的热情正在持续升温，但就像对待任何技术行业的趋势都应该客观冷静一样，对待微服务架构也是如此。虽然目前微服务架构大行其道，但不应该因为这种趋势而盲目地对应用进行优化和改造。除非是一个创业公司，否则很可能在短时间内就要面临混合架构带来的各种问题。
微服务最大的优势在于， 不需要在同一个周期里面对系统的若干部分进行升级改造。整个系统不需要部署在一起，各个服务可以单独进行部署。如果只需要做很小的改动，不必等到下一个发布周期，因为仅仅修改了整个系统中的一个微服务组件，单独部署这个微服务就可以了。
然而，微服务不是应对所有软件开发和交付问题的灵丹妙药。除非对所有细节问题都了如指掌，否则很容易出错。这四个建议能帮助您在使用微服务的时候充分利用其优势，尽量避免相关的问题。
如果计划将现有的应用向微服务架构迁移，那么必须对系统有着非常深入的了解，并且对各个服务之间如何交互有着清晰的认识。盲目地将整体应用拆分成微服务应用是非常不明智的选择。
对数据模型的任何改动都会对最终的工作量和成本造成直接的影响，这些改动可能是为每个微服务配置单独的数据库，或者是每个微服务一张数据表，也可能是对外键的更新。
总之，我的建议就是：在开发之前先将数据进行拆解。
采用微服务架构之后，大部分开发者都希望有一个更好的自动化部署流程，这个流程直接覆盖代码签入到生产环境，与此同时也希望更方便地对整个环境进行监控。有可能当我们发现一个微服务有问题时，真正的问题源头在上游的某个服务。在这种情况下，我们就需要自动回滚有问题的服务，或者在蓝绿发布之间切换。
微服务通常倾向于部署在容器中，因为容器提供了很好的隔离机制，而且很容易地创建和删除，并且只是运行一个进程而已。容器相对于虚拟机来说，占用资源更少，因此资源利用率有着显著提升。
但是如果100个服务运行在100个容器中，将面临运维和管理双重困境。部署将变得更复杂，监控、日志和故障恢复也将越来越重要。
大规模地运行容器和微服务所需要的技能要求还是比较高的，目前很多组织尚不具备这种能力。但是每一个团队负责一个单一的应用则难度大大降低。无论从技术还是文化角度来说，在微服务的领域里，我们所熟知的DevOps和持续交付变得尤为重要。
微服务虽然是堪称伟大的架构，但即使新开发的应用全部采用微服务架构，也不得不面临如何处理遗留应用的问题。任何一个企业组织，尤其是大型组织机构，都不会使用单一的软件架构。他们可能有成千上万的各种类型应用程序，有的传统老旧，有的部署在大型机上，有的用的是Java语言，而有的使用COBOL。真正的挑战是如何管理所有的产品交付渠道，怎样将代码变成生产环境中可用的产品，以及如何设计产品交付流水线。
【上海站｜3天烧脑式微服务架构训练营】培训内容包括：DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。
微服务是一个杰出的架构，因为这种架构便于对软件系统进行管理。但实际情形是，有很多遗留的应用并没有采用微服务架构，也必须纳入统一的管理范畴。任何一个企业组织，尤其是大型组织机构，都不会使用单一的软件架构。
企业拥抱微服务架构的热情正在持续升温，但就像对待任何技术行业的趋势都应该客观冷静一样，对待微服务架构也是如此。虽然目前微服务架构大行其道，但不应该因为这种趋势而盲目地对应用进行优化和改造。除非是一个创业公司，否则很可能在短时间内就要面临混合架构带来的各种问题。
微服务最大的优势在于， 不需要在同一个周期里面对系统的若干部分进行升级改造。整个系统不需要部署在一起，各个服务可以单独进行部署。如果只需要做很小的改动，不必等到下一个发布周期，因为仅仅修改了整个系统中的一个微服务组件，单独部署这个微服务就可以了。
然而，微服务不是应对所有软件开发和交付问题的灵丹妙药。除非对所有细节问题都了如指掌，否则很容易出错。这四个建议能帮助您在使用微服务的时候充分利用其优势，尽量避免相关的问题。
在开发之前对数据进行拆解
照在微服务的角度，可以将整体应用看作是一组服务，每个服务负责解决问题的不同部分。电子商务应用是一个典型的微服务架构案例。用户需要登录，浏览产品目录，根据推荐信息购物，操作购物车和付款操作等独立的功能。如果计划将现有的应用向微服务架构迁移，那么必须对系统有着非常深入的了解，并且对各个服务之间如何交互有着清晰的认识。盲目地将整体应用拆分成微服务应用是非常不明智的选择。
对数据模型的任何改动都会对最终的工作量和成本造成直接的影响，这些改动可能是为每个微服务配置单独的数据库，或者是每个微服务一张数据表，也可能是对外键的更新。
总之，我的建议就是：在开发之前先将数据进行拆解。
在原型基础上逐渐迭代扩大
如果希望从零开始写一个应用，那么最好从一个最基本的原型开始迭代。首先，梳理清楚业务域是什么，数据关系是怎样的。处理的数据是关系数据还是事务数据。这些问题的答案对于数据结构至关重要。在将应用重构成微服务架构之前，先搞清楚系统中的依赖关系。采用微服务架构之后，大部分开发者都希望有一个更好的自动化部署流程，这个流程直接覆盖代码签入到生产环境，与此同时也希望更方便地对整个环境进行监控。有可能当我们发现一个微服务有问题时，真正的问题源头在上游的某个服务。在这种情况下，我们就需要自动回滚有问题的服务，或者在蓝绿发布之间切换。
关注内部服务之间通信细节
服务虚拟化和服务内部通信将带来一些严重的问题。采用微服务架构最重要的一个考量就是有良好的API定义，方便服务发现和彼此之间的交互。开发者使用的是REST，http还是JSON已经变得不再重要，重要的是他们如何使用协议来实现健壮的服务间通信。当服务间的通信由于接口设计不当而产生延迟或者中断时，整个系统就会出现问题。微服务通常倾向于部署在容器中，因为容器提供了很好的隔离机制，而且很容易地创建和删除，并且只是运行一个进程而已。容器相对于虚拟机来说，占用资源更少，因此资源利用率有着显著提升。
但是如果100个服务运行在100个容器中，将面临运维和管理双重困境。部署将变得更复杂，监控、日志和故障恢复也将越来越重要。
确保开发技能满足架构需要
将应用拆分成微服务形式之后，每个服务都可以使用不同的技术来实现。一个服务使用Java来实现，另一个头像服务是通过静态内容呈现的，再或者用Apache实现其他服务。你可以建立起一个个小型的团队，这些团队彼此依赖，他们负责开发各自的服务，从此再也不用为管理大型团队而担忧。每个团队负责管理自己的产品发布周期，不必被整个产品的发布周期所影响。大规模地运行容器和微服务所需要的技能要求还是比较高的，目前很多组织尚不具备这种能力。但是每一个团队负责一个单一的应用则难度大大降低。无论从技术还是文化角度来说，在微服务的领域里，我们所熟知的DevOps和持续交付变得尤为重要。
微服务虽然是堪称伟大的架构，但即使新开发的应用全部采用微服务架构，也不得不面临如何处理遗留应用的问题。任何一个企业组织，尤其是大型组织机构，都不会使用单一的软件架构。他们可能有成千上万的各种类型应用程序，有的传统老旧，有的部署在大型机上，有的用的是Java语言，而有的使用COBOL。真正的挑战是如何管理所有的产品交付渠道，怎样将代码变成生产环境中可用的产品，以及如何设计产品交付流水线。
原文链接：4 Rules for Microservices and Software Delivery （翻译：付辉）
原文发布时间为：2017-03-14
本文作者：付辉
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：微服务和软件交付的4个原则
