微服务架构与持续交付关系

    本文主要参考《微服务架构与实践》（王磊，博文视点，2016.1），架构师必看：微服务架构综述 - 帐前卒 专栏 - CSDN博客
https://blog.csdn.net/cctt_1/article/details/78344253，https://www.jianshu.com/p/be52eeb5e9a5  简书-微服务架构，对应探讨。

一、微服务架构基础

 1、概述       

        传统主流的系统架构，虽然在逻辑上是分层的，但在构建和部署上并不是分层的（注：参考书是说物理上不分层），即使物理上按照分布式部署，只是解决负载均衡和水平扩展。这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序，可以称为单块架构，典型的就是三层架构，包括表示层、业务逻辑层和数据访问层，模型就是MVC模式。

        微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相协作（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，对具体的服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建 。（摘自王磊的《微服务架构与实践》）

         简而言之，有两个关键点：一是把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。二是采用轻量级的通信机制互相协作，这个是其与SOA差别的重要地方。

   2、   单块架构和微服务架构比较 

   红色代表优势，黑色为劣势，棕色为不确定。

单块架构	微服务架构
易于开发（IDE 支持好） 易于测试（全部运行在一个进程中）	目前的技术团队、IDE支持等还不够好 必须作好服务间的依赖测试 不许做好服务间的依赖管理
易于部署（打好的一个软件包发布） 易于水平伸缩（应对用户数暴涨，创建服务器节点扩展即可）	部署自动化要求高 （分布式系统复杂度、服务作为组件、技术多样性）
		维护成本大	维护方便（基础较好情况下）
		持续交付周期长（所有功能互相牵扯--分层多，块头大）	持续交付周期短（服务作为组件，应用可以独立部署；业务数据独立；围绕业务组织团队）
		业务功能可扩展性差（垂直业务功能扩展困难，部分程序的功能水平扩展也困难）一起构建和部署--分层多，块头大）	扩展性好，水平伸缩不如单块式架构（服务作为组件，应用可以独立部署；业务数据独立；演进式开发）
新人培养周期长（必须熟悉全部业务和环境--分层多，块头大）	人员团队更稳定、更持续发展（围绕业务组织团队、关注产品而非项目）
	可能会需要做好组织的架构调整和文化转型（DevOPS）
技术选型成本高（新技术不好进来，基本只能采用统一平台才能通信	技术多样性好（独立组件）

3、SOA与微服务比较  

本质上微服务架构也是SOA，但是和传统的SOA实现比较，有很大不同（注：其实应该考虑到90年代的业务、技术、软硬件环境和现在的差异，才能深刻体会时代的洪流）：

传统的SOA实现	微服务实现
企业级，自顶向下开展实施	团队级，自底向上开展实施
服务由多个子系统组成，粒度大	一个系统被拆分成多个服务，粒度细
企业服务总线，集中式的服务架构	无集中式总线，松散的服务架构
集成方式复杂（ESB/WS/SOAP）	集成方式简单（HTTP/REST/JSON）
单块架构系统，相互依赖，部署复杂	服务能独立部署

二、微服务架构与持续交付的关联    

        

1、微服务架构产生的背景

        最根本的就是，时代的发展。一，互联网行业的快速发展，带来的需求变化： 对时间和速度追求，快是关键，带来的需求变更多，系统要求可伸缩、高可用，不断迭代更新等。二、技术层面的发展，软件开发模式例如敏捷、精益方法论的深入人心，硬件技术和基础设施层面，伴随网络基础设施的高速发展和硬件计算能力提升，带来的云计算服务、容器虚拟化技术发展。 

       单块架构就面临一系列困难，上面说的各项弱点被放大，而微服务架构的维护方便、持续交付周期短、扩展性好、技术多样性好等优势充分体现。

      微服务产生关键背景，就是由于持续交付的需要。显然持续交付对微服务架构成立起到支撑，必须做到：1、版本控制，否则服务依赖完全乱套；2、自动化测试，多个服务间的依赖测试，靠人工显然困难；3、自动构建；4、集成自动部署。