作者：任钢
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
微服务设计：企业架构转型之道试读：
前言
本书定位本书涉及两个方面的知识体系，即企业架构知识体系和软件架构知识体系。企业架构和软件架构虽然都与IT相关，但其知识体系是完全不同的两个领域。一般而言，搞企业架构的人士不明白软件架构的细节和实现，而从事软件架构的架构师又缺乏企业架构的整体布局。企业架构是一个公司的核心业务流程，是企业IT建设的组织逻辑，由一组原理、政策和技术选择构成，目的是实现公司运营模型的业务标准化和集成需求。软件架构是企业架构具体落地时的技术实现工具和手段。微服务架构实际上是一种软件架构，当然，本书所涉及的微服务不仅仅是技术层面的微服务架构，还是一个概念微服务体系。但微服务架构只是微服务体系的一个组成部分。本书的核心思路是把企业总体架构规划与具体落地的软件架构及微服务体系结合在一起，构建企业在业务层面、技术层面、管理层面等多个方面的立体化体系。
本书不是一本完全理论化的教科书，而是采用理论结合实际的方法，提出具体问题、分析具体问题并且解决具体问题的书籍，实践性和可操作性都很强。如何使用本书
本书可以给公司多个层次的架构规划者和微服务使用者提供指导和帮助。
对于初次采用微服务框架的企业，IT 规划师可以先从整体上了解整个企业架构和微服务的大致轮廓和状况，然后针对自己的专业和实际工作要求做到有的放矢。
中级层次的读者往往拥有非常丰富的微服务应用经验，他们或许在某个微服务框架上娴熟无比，本书仍然可以帮助这些读者在实际应用中拓展知识面，开阔视野，在思维上进行综合并融会贯通，从而踏上一个新的台阶，达到更高的理论层次。
技术公司的CTO和信息化公司的CIO等高层领导很少有机会在一线作战，对于一线出现的各种名词概念，可能很难准确地掌握每一个细节。针对这类读者，本书提纲挈领地阐述了微服务的体系架构，让IT领导从一个新高度迅速地了解和掌握整个企业架构和微服务的状况，然后在战略层面上做出适合公司或组织的微服务体系建设决策。本书结构
本书主要包括4个部分，分别是企业数字化和微服务概述、企业架构规划、企业架构微服务化实施和企业架构微服务化管理和治理，总共12章。
本书首先说明了企业数字化及其转型的阶段，引入了企业架构的规划和实施，接着讲述了企业架构的规划，包括业务架构、应用架构、数据架构和技术架构。然后依次介绍了企业架构的服务化过程、企业服务架构微服务过程、企业微服务架构的治理和管理。
第1部分企业数字化和微服务概述包括第1～3章。
■ 第1章为企业数字化概述。首先说明企业数字化转型的内容和方式；其次说明企业数字化转型的4个步骤；再次说明企业数字化转型的方法；最后说明何为企业架构，阐述了企业架构的概念和TOGAF框架的内容。
■ 第2章为微服务及微服务架构概述，主要介绍了服务、微服务、SOA 架构、微服务架构、微服务体系等概念和基本情况。首先说明服务及其服务架构的概念；其次比较了微服务架构和 SOA 架构之间的区别和联系；最后介绍微服务体系的概念，并对微服务体系进行了定义。
■ 第3章主要讲述企业微服务体系化情况。首先说明了企业为什么要微服务化；其次介绍了企业引入微服务的5个难点；接着阐述了企业微服务化的原则和策略；然后介绍了企业微服务实施的方法；最后详细说明了企业实施微服务的8个阶段步骤。
第2部分是企业架构规划，包括第4～6章。
■ 第4章主要讲述企业架构规划。首先说明了企业架构规划的概念；其次说明了企业架构规划的内容；最后说明了架构的5个规划步骤。
■ 第5章主要讲述企业的业务架构规划。首先说明了企业业务架构规划的概念；其次说明了企业的业务架构规划体系内容；最后说明了业务架构的5个规划步骤。
■ 第6章主要讲述企业IT架构的规划。首先说明了企业IT架构规划的概念；其次讲述了企业应用架构规划的内容；然后讲述了企业数据架构规划的内容；最后讲述了企业技术架构规划的内容。
第3部分为企业架构微服务化实施，包括7～9章。
■ 第7章主要讲述企业架构服务化。首先说明了何为企业架构服务化；其次说明了企业架构服务的抽象过程；再次说明了企业服务架构内容；最后是企业服务的成熟度进展评价。
■ 第8章主要讲述企业服务架构微服务化。首先说明了何为企业服务架构微服务化；其次说明了企业业务微服务架构的形成过程；最后说明了企业应用微服务架构的形成过程。
■ 第9章主要讲述企业技术架构微服务化。首先说明了何为企业技术架构微服务化；其次说明了企业微服务技术架构的内容和组成；接着说明了企业集成技术架构的内容和组成以及企业基础设施架构的内容和组成；然后说明了企业集成工具平架构的内容和组成；最后说明了企业API开放生态平台的内容和组成。
第4部分是企业架构微服务化的管理和治理，包括第10～12章。
■ 第10章主要讲述企业IT治理与微服务治理的关系。本章首先说明了何为企业的IT治理；接着说明了企业服务治理内容。
■ 第11章主要讲述企业微服务治理体系。本章首先说明了何为企业的微服务治理体系；然后是企业微服务治理方案。
■ 第12章主要讲述企业微服务管理体系。首先说明了何为企业微服务体系；其次介绍了企业微服务的组织模式；接着介绍了企业 DevOps 的实现方法；然后介绍了企业微服务的度量标准；最后说明了企业微服务应用成熟度级别。读者对象
本书的读者对象主要覆盖以下几类人群。
■ 企业决策者和管理者，如 CTO、CIO、技术总裁、技术总监、研发总监、信息总监等。通过阅读本书，他们一方面可以了解企业架构，另一方面也可以通过了解微服务的整个蓝图，在企业或组织微服务体系建设中做出高质量的决策。
■ 企业规划架构师和分析师，尤其是传统企业要转型到互联网时代的IT工作者。
■ 有丰富经验的企业架构师和分析师。通过阅读本书，他们可以从更深层次去理解微服务的本质和核心，可以更游刃有余地解决企业实际工作中的架构问题。
■ 软件开发工程师，包含有微服务应用经验的软件开发工程师、需求分析师、运维工程师等。勘误和支持
由于笔者水平有限，书中的纰漏和错误在所难免，希望读者给予批评和指正。笔者的联系邮箱：rengang66@sina.com。第1部分 企业数字化和微服务概述
本部分主要描述企业数字化的内容和企业微服务体系的方法论和规划过程。
首先介绍企业数字化转型，包括企业数字化转型的概念、步骤和方法，以及其中引入的企业架构规划和实施的概念。
接着概述了微服务以及微服务架构，包括服务和服务架构概念、微服务架构和 SOA架构之间的关系、微服务体系概念等。
最后概述了企业微服务体系，包括企业为什么要微服务化，企业引入微服务的难点、原则和策略，以及企业微服务实施方法论等。第1章 企业数字化概述1.1 企业数字化转型
随着云计算、大数据、物联网、人工智能、5G移动互联网等新型技术的出现和应用，互联网时代的数字化浪潮扑面而来，传统企业面临着新的挑战和机遇。
企业是经济活动的主体，企业数字转型是产业数字化的基石，通过推动产业战略思维、组织架构、业务流程、商业模式、人才培养等全方位转型，驱动企业效率提升、产品增值、流程再造、生态构建、就业变革等，可以深刻改变企业的能力和价值主张，进而带动提升整个行业的运行效率，推动产业发展沿数字化、网络化、智能化路径加速转型。
企业数字化转型可以表现在下面几个方面。
业务方面：1）采用互联网思维实现企业内部端到端运营流程；2）企业的前台与后台紧密结合在一起。3）紧密围绕客户体验和需求，整合企业的运作、决策及服务模式；4）打通企业内部与外部信息化；5）使企业的运作、决策及服务紧密围绕客户价值和体验而进行；6）通过数字化的有机整合，为企业各个层级提供动态、及时信息，以支持企业各个层级做出最优决策。如图1-1所示。图1-1 企业数字化的表现
技术方面：1）高度互联，即随时随地沟通；2）无限制的IT能力，包括计算能力和存储能力；3）混合云模式，公有云、私有云等相结合，轻松访问托管的软件和服务；4）数据采集点，通过传感器和移动设备激增，提供新的源源不断的信息流，以及大量的信息访问渠道；5）信息安全，支持用户安全地访问和使用重要信息，最小化内外部安全漏洞。
不同行业、不同企业和企业不同阶段的业务和流程差异非常大，数字化转型的具体路径也会有差别，但它们有一个共性，即数字化的企业架构，表现在3个方面：第一是行业与企业架构的结合程度；第二是数字化的投入方向；第三是数字化的企业IT架构。
第一，数字化企业架构与行业的结合深度可采用投资回报周期作为标准。投资回报周期过长或过短，都意味着数字化企业架构与行业结合比较松散。只有将行业前景与数字化企业IT 系统及其业务系统进行良好融合，才能得到恰当的投资回报周期，实现高质量的数字化转型。
第二，在企业的数字化转型过程中，如果投入都被用在购买IT 硬件产品等基础设施上，那说明这个企业的数字化转型还停留在基础层面；当投入被用在业务深度分析上时，才说明数字化转型已经达到比较高级的程度了。
第三，可以通过企业的IT 架构来判断数字化转型的程度。企业数字化转型也是一个循序渐进的过程，主要包括以下阶段：第一阶段是单一应用时代；第二阶段是EAI集成时代；第三阶段是SOA时代；最后一个阶段是所谓的微服务时代，其代表内容包括云原生、DevOps、混合云、敏捷开发等。1.2 企业数字化转型的步骤
企业数字化转型，要从企业整合运作、提升竞争力的角度出发，站在企业全局的高度，从理解企业所处行业、发展阶段、目标、战略、竞争环境等多方面入手，认清其核心能力及管理中存在的主要问题，在此基础上进行管控模式分析，提出关键业务流程的优化建议；确定总体的目标，提出需求报告；通过全面、客观的分析，根据企业的数字化需求及约束条件，提出实施方案；在项目的整个过程之中有针对性地对企业开展相关实践和培训，以奠定企业实施数字化的思想基础和技术基础，如图1-2所示。图1-2 企业数字化转型的步骤图
企业数字化转型主要分4个阶段：
1.企业战略——评估和分析
通过访谈，了解企业所处行业、目标、发展阶段、战略、优势、劣势、信息化基础等，认清其核心竞争力，确定公司的战略，基于战略形成组织架构、流程框架、业务逻辑框架等，帮助企业发现和判断经营管理活动中最为紧迫的信息化需求和亟待解决的瓶颈问题。正确分析并找出问题是成功的前提，要真正把信息化工程从技术层面提升到管理和战略层面，提升企业的核心竞争力。
2.企业架构规划——提出整体解决方案
充分考虑企业的实际情况、现实约束、未来发展等方面的问题，从企业全局出发，遵循体系化和整体化思路，以企业架构为基础，覆盖企业整体的业务架构、应用架构、数据架构和技术架构，构建IT总体架构并形成IT治理架构规划，不拘泥于具体的产品或系统，为企业提供科学、合理、可行的个性化、专业化解决方案。
3.企业IT实施方案——企业如何去做
基于企业架构整体规划和IT战略，以支持企业战略实施需要为原则，构建IT项目并根据轻重缓急分阶段实施。分析、明确各阶段实施的前提条件、风险、投入及成效。推进IT项目的建设，指导IT投资和设计决策。
4.治理运维——企业如何去维护
阐明对一系列IT战略、资源和控制行为的监督、问责机制并确定决策权分布。具体来说，IT治理即通过相关决策权分布对投资、规划、预算、承诺、服务、主要变革、安全、隐私、业务连续性以及法律法规合规性进行授权控制和绩效度量，是对政策、实践、流程进行管理、规划和绩效评估的集合。1.3 企业数字化转型的方法
企业数字化在各个阶段都需要一些方法来支撑，这些方法主要包括企业数字化评估方法、企业数字化规划方法、企业数字化实施方法和企业数字化治理方法。下面对该领域的常用方法进行说明。
1.3.1 企业数字化评估方法
企业数字化评估主要是对企业数字化工作的现状进行梳理、分析和评价，有3方面的作用：第一，对企业信息化实施的成果作出客观的反映；第二，为企业信息化的科学决策提供有力支撑；第三，为企业信息化的发展方向进行正确的引导。
国外的评估方法有信息系统（IS）成功模型、ERP 评估体系、ABCD 测评表等。
■ IS成功模型于1992年由美国研究人员提出，在信息化系统实施效果评估领域具有里程碑意义。该模型将信息化实施成功视为一个具有时间跨度和因果关系的过程，认为质量层面的指标既共同又相对独立地影响着用户满意度及系统使用指标，而用户满意度、系统使用之间又互相产生影响，分为积极的影响和消极的影响。用户满意与否和系统使用状况决定了对个人的影响，最终产生对组织的影响。
■ SAP 公司与 Benchmarking Partners 的 ERP 评估体系主要利用关键成功类因素、事务处理类指标和项目驱动类因素三大类因素指标来对信息化建设进行评估。
■ ABCD 测评表从控制与计划、战略规划、研发创新、人员素质与协作、全面质量管控、持续改进6个角度来对信息化系统实施效果进行评测。
■ 常见的评估理论还有 Markus等人研究提出的评价阶段论，它分别从项目的标准、早期运营标准、长期收益3个角度去考评信息化系统实施效果。
根据对企业信息化系统实施效果评估方法的研究，目前国内最常用的方法包括主成分分析法、层次分析法、因子分析法、数据包络分析法、平衡计分卡、灰色聚类分析和模糊综合评判法等。
1.3.2 企业数字化规划方法
1.企业系统战略规划理论方法
简要介绍其中3种方法，分别是企业系统规划方法、战略数据规划方法、信息化战略工程方法。
■ 企业系统规划方法（Business System Planning，BSP）——由IBM在20世纪70年代提出，其从企业目标入手，逐步将企业目标转化为管理信息系统的目标和结构，从而更好地支持企业目标的实现。这是一种战略规划的结构化方法，通过这种方法可以确定未来信息系统的总体结构，明确系统的子系统组成和开发系统的先后顺序；对数据进行统一规划、管理和控制，明确各子系统之间的数据交换关系，保证信息的一致性。
■ 战略数据规划方法——这一概念是美国的詹姆斯· 马丁（James Martin）教授提出的，是指遵循数据库的规则，通过一系列步骤来建造组织的总体数据模型。该模型是按实体集群划分的、针对管理目标的、由若干个主题数据库概念模型构成的统一体。在实施过程中，既有集中式又有分布式，可以分期分批地进行企业数据库构造。主要步骤包括3步：1）进行业务分析，建立企业模型；2）进行数据分析，建立主题数据库；3）根据主题数据库和业务过程，进行子系统划分。
■ 信息化战略工程方法——要求企业战略的制定和实施都以高效、可靠的信息化为基础，从企业发展全局考虑，把企业作为一个有机整体，根据企业发展目标、经营策略和外部环境以及企业的管理体制和管理方法，用系统的、科学的、发展的观点对企业信息化进行系统的、科学的规划，从而为企业整体战略实施提供最大限度的信息保障。其建设思路包括：1）从企业战略实现角度出发；2）坚持理论研究成果与企业实际相结合；3）重视企业信息化的内外部环境；4）总体规划、分步实施；5）强调内外合作策略；6）尽量保护已有投资。
2.企业架构规划理论相关方法
企业架构（Enterprise Architecture）是国际上先进的信息化架构规划框架模型。经过30多年的持续发展，企业架构理论已经形成了一套比较系统的理论和方法体系，架构演进为两个主要的方向：以Zachman框架为基础发展演进的EAP、FEAF、TEAF等架构，和以ISO/IEC14252为基础发展演进的 TAFIM、DoDTRM、C4ISR、DoD-AF、TOGAF 等架构。目前，两个方向的多种架构在定义、组成和实施等方面趋于相同，已经逐渐相互融合。下面进行简单介绍。
■ Zachman架构——20世纪80年代中期由IBM的John Zachman率先提出的概念。Zachman架构从信息、流程、网络、人员、时间、基本原理等6个透视角度来分析企业。该理论提供了与这些视角相对应的6个模型，包括语义、概念、逻辑、物理、构件和功能等。企业架构的核心目标是保持拟设计的信息系统与其业务的动态一致性，包括业务架构和IT架构。
■ FEAF（Federal Enterprise Architecture Framework）——FEAF是美国联邦政府 CIO委员会在1999年的研究报告中提到的“联邦政府组织架构框架”。联邦企业体系结构（FEA）计划确定了联邦政府可以简化流程、降低成本，并跨机构和业务线共享信息和资源。FEA 由管理和预算办公室开发，是一个商业驱动框架，可提供更加以公民为中心、注重成果和以市场为基础的服务。
■ TOGAF（The Open Group Architecture Framework）——TOGAF是 Open Group开发的一个总体框架理论，目前发展已经较为成熟。TOGAF 基于4个相互关联的专业领域描述组织逻辑和物理数据资产结构以及相关数据管理资源。应用程序体系结构为要部署的各个系统提供蓝图、应用程序系统之间的交互以及与组织的核心业务流程之间的关系，其中服务的框架将作为集成的业务功能，技术体系结构描述支持部署核心关键任务应用程序所需的硬件、软件和网络基础架构。TOGAF 的核心是应用体系结构开发方法（ADM）。ADM 可以根据组织的需求量身定做，然后用于管理架构计划活动的执行。该过程是迭代和循环的，每个步骤都会检查需求。
■ 军队指挥体系总体框架（DoDAF/C4ISR）——DoDAF借鉴了美国国防部总体架构的基本原则，以3种协调的角度定义整个与国防有关的信息系统总体架构，目的是确保各个指挥组织、服务提供和各个部门的系统和架构描述是一致且协调的。DoDAF 定义了26个架构产品，由全局、运行作战、系统和技术标准组成。各种架构相互融合，具体应用时需针对具体应用场景，开发具有自身特点的架构标准框架和方法。
■ Gartner方法——Gartner既不提供企业架构内容的分类法，也不提供企业架构的建设过程指南，其将企业架构看成一个动态的过程，企业架构建设的起点应该是对企业发展方向的明确，一个成功的企业架构应该能将业务拥有者、信息专家和技术实现者联系起来，并为他们提供一个统一的针对企业现状和发展方向的愿景。
1.3.3 企业数字化实施方法
企业数字化实施方法与企业架构的分析、设计和实施内容都相关，下面列举其中主要的3种方法。
■ 结构化方法（Structured Approach）——结构化方法也称生命周期法，结构化最早是描述结构化程序设计方法的，它用3种基本逻辑结构来编程。将整个信息系统开发过程划分为6个独立的阶段，包括系统分析、程序设计、系统测试、运行、维护以及系统评估。这6个阶段构成了信息系统的生命周期。结构化方法不仅提高了编程效率和程序清晰度，而且大大提高了程序的可读性、可测试性、可修改性和可维护性。后来，结构化程序设计思想被引入 MIS 开发领域，逐步发展成结构化系统分析与设计方法。结构化方法按软件生命周期划分，有结构化分析（SA）、结构化设计（SD）、结构化实现（SP）3种。结构化方法的基本要点是自顶向下、逐步求精、模块化设计、结构化编码。具体来说，结构化分析方法是以自顶向下、逐步求精为基点，以一系列经过实践考验的正确的原理和技术为支撑，以数据流图、数据字典、结构化语言、判定表、判定树等图形表达为主要手段，强调开发方法的结构合理性和系统结构合理性的软件分析方法。
■ 面向对象（Object-Oriented，OO）方法——面向对象方法是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法。面向对象方法遵循一般认知方法学的基本概念——即有关演绎——（从一般到特殊）和归纳——（从特殊到一般）的完整理论和方法体系来建立基础。所谓面向对象就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。该方法包括面向对象的分析（Object Oriented Analysis，OOA）、面向对象的设计（Object Oriented Analysis，OOD）和面向对象的实现（Object Oriented Implementation，OOI）。
■ 面向服务架构方法（Service-Oriented Architecture，SOA）是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型。SOA 实施方法站在一个新的高度理解企业级架构中各种组件的开发、部署形式，将帮助企业系统架构者更迅速、更可靠、更具重用性地架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。实施SOA的关键目标是实现企业IT资产的最大化作用。要实现这一目标，就要在实施SOA 的过程中牢记以下特征：可从企业外部访问；随时可用；粗粒度的服务接口分级；松散耦合；可重用的服务；服务接口设计管理；标准化的服务接口；支持各种消息模式；精确定义的服务契约等。
1.3.4 企业数字化治理方法
自从人们提出IT治理以来，世界各国专家组织投入了极大的精力去研究IT治理的模型，在IT治理领域已经有几种较为成熟的治理模型，如信息及相关技术的控制目标（Controlled Objectives for Information and related Technology，COBIT）模型、信息技术基础架构库（Information Technology Infrastructure Library，ITIL）模型、ISO 27001模型等。以下对上述模型进行介绍。
■ COBIT模型——COBIT模型是信息系统审计和控制协会（ISACA）制定的面向过程的信息系统审计和评价的标准。对信息化建设成果的评价，按照系统属性可以划分为若干方面，例如对最终成果评价、对建设过程评价、对系统架构评价等。COBIT 是一个基于IT治理概念的、面向IT建设过程的IT治理实现指南和审计标准，也是一个典型的按照西方思维方法取得的研究成果，即分析事实、提炼模型，并将IT过程、IT 资源及信息与企业的策略和目标联系起来，形成一个三维体系结构。
■ ITIL 模型——ITIL 由英国政府部门中央计算和电信局（Central Computing and Telecommunications Agency，CCTA）在20世纪80年代末制定，现由英国商务部负责管理，主要适用于IT服务管理（ITSM）。ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范，企业的IT部门和最终用户可以根据自己的能力和需求定义所要求的不同服务水平，参考ITIL来规划和制定其IT基础架构及服务管理，从而确保IT服务管理为企业的业务运作提供更好的支持。ITIL作为IT服务的一个管理框架，其核心的流程就是提供优质的“服务管理”，是一个负责持续管理、交付和支持服务的技术。
■ ISO/IEC38500标准——2008年4月，ISO/IEC正式发布IT治理标准ISO/IEC 38500，它可以用于任何规模的组织，包括公/私有性质的公司、政府机构以及非营利组织。这一标准提供了一个IT治理的框架，以协助组织高层管理者理解并履行他们对于其组织IT使用的既定职责，实现IT治理的有效性、可用性及效率。ISO/IEC 38500提出了IT治理的EDM模型，其与管理者使用的典型PDCA模型稍有不同。在这一模型中，管理者依据业务压力、监管责任、利益相关者期望及业务需求来监督、评估和组织的IT使用，而后指导实施政策方针以弥补差距。ISO/IEC38500给出了IT治理的基本、原则性建议，定义了组织开展IT治理的6个基本原则，并结合EDM模型的应用，形成了IT治理的相关任务和要求。1.4 企业架构概述
1.4.1 企业架构概念
企业架构（Enterprise Architecture，EA）的定义在概念上没有统一标准。国内外很多专家学者从不同角度都做过探讨和分析。其中代表性的是约翰·扎科曼（John Zachman）在其1987年出版的书籍《信息系统架构框架》中提出的企业架构理论，这是目前被广泛实践和认可的有关企业架构的权威理论。Zachman 框架在1996年被《克林格-科思法案》（Clinger-Cohen Act）做了进一步的延伸。它将企业架构定义为一个集成的框架，用于演进或维护已存在的信息技术和引入新的信息技术，以实现组织的战略目标和信息资源管理目标。另外，微软、IBM和国际化开发组织都有自己的定义和研究。
微软认为，企业架构是一个公司的核心业务流程和IT能力的组织逻辑，通过一组原理、政策和技术选择来获得，以实现公司运营模型的业务标准化和集成需求。
IBM的观点为，企业架构是记录企业内所有信息系统及其相互关系，以及它们如何完成企业使命的蓝图。
国际化开发组织（The Open Group）的定义为，企业架构是对所有构成企业的不同企业元素，以及这些元素怎样相互关联的理解。
尽管企业架构的描述各不相同，但有一点是可以明确的即企业架构是企业的战略组成部分，旨在帮助企业有效地组织资源和完成 IT战略规划。企业架构的整体组成如图1-3所示。图1-3 企业架构的整体组成图
一个企业架构具有3个方面的含义：
第一，企业架构是一个描述工具。企业架构为组织中的所有干系人提供了一种描述手段（模板），使其可以对组织中的业务、信息系统及其之间的关系按照各自的视角进行描述。而且由于使用统一的语言进行描述，所有干系人之间也有了无障碍沟通的基础，而这也正是企业架构最重要的作用。
第二，企业架构是一个知识库。企业架构为组织中所有参与者提供的针对企业架构各方面的描述形成了一个分类管理、便于访问的知识库和信息资源库。
第三，企业架构是一个系统过程。为了使组织内信息技术与业务的需求、变化相适应，企业架构提供了一套实施准则和管理策略。
根据 ANSI/IEEE-1471-2000标准中的定义，架构（Architecture）是系统的基本组织，包括其组成部分、相互关系和环境，以及指导其设计和演化的原则。
按照这个原则，可以将企业架构定义为：企业架构涉及的系统是整个企业，特别是企业的业务流程、技术和信息系统。企业架构是一个系统过程，它表达了企业的关键业务、信息、应用和技术战略以及它们对业务功能和流程的影响，是对企业多层面、多角度的建构和描述，主要包括业务架构、应用架构、数据架构和IT架构。企业架构是承接企业战略与IT系统的桥梁与标准接口框架。
1.4.2 TOGAF框架
有很多不同类型的企业架构框架方法，TOGAF框架是众多企业架构框架理论中的一种。TOGAF 通用性较强，完整性和实用性都比较高，为一个企业或组织对于企业架构的接受、创建、使用和维护提供了一系列辅助方法和工具。同时 TOGAF 还是一个基于迭代过程模型的企业架构框架理论，作为支持该过程模型的重要基石，TOGAF包括了各种最佳实践，以及一系列可重用的现有企业资产。简而言之，TOGAF 是一种协助发展、验收、运行、使用和维护架构的工具，可帮助企业设计、评估并建立机构的正确架构，内容涵盖了企业架构生命周期中的方方面面，所以现阶段的企业架构咨询中经常使用TOGAF框架为客户进行架构规划。TOAGF架构框架的内容如图1-4所示。
从图中我们可以看出，TOGAF的内容被分为3个主要部分：
第一部分是架构原则，愿景和需求。其覆盖的内容有战略、业务原则、业务目标、驱动力和利益相关者等。
第二部分是架构的3个组成部分，分别是业务架构、信息系统架构和技术架构。
第三部分是架构的实施。从实施内容来看，涉及机会、解决方案、架构契约和迁徙规划。从过程来看有架构实施和架构治理两个阶段。图1-4 TOAGF架构框架的内容1.5 本章小结
本章主要讲述了企业数字化的基本情况，共4个部分内容。
■ 首先说明企业数字化转型的内容和方式，包括业务的转型和技术层面上的转型。数字化转型的具体路径也有3种。
■ 其次说明企业数字化转型的步骤，主要有4步：1）企业战略——评估和分析；2）企业架构规划——提出整体解决方案；3）企业IT实施方案——告诉企业如何去做；4）治理运维——告诉企业如何去维护。
■ 再次说明企业数字化转型的方法。按照各个阶段分为企业数字化评估方法、规划方法、实施方法和治理方法。
■ 最后概述企业架构，主要阐述了企业架构的概念和TOGAF框架内容。企业架构没有一个统一的标准，但有一些共性的特征。TOGAF框架是企业架构框架中比较有代表性的框架，可以独立应用，也可以根据企业具体情况有选择地使用。第2章 微服务及微服务架构概述2.1 服务及其相关架构服务概念
2.1.1 服务概念
服务是什么？这个问题比较复杂。
1.服务的定义
服务这个概念是伴随着 SOA 概念提出来的。多年来，服务本身的含义已经发生了天翻地覆的变化，如何定义服务成了难题。无论是 SOA 架构、微服务架构，还是企业架构等，对服务的概念都有各自不同的定义。如果对服务这个名词定义不清晰，后面所讲的内容会混乱不堪，因此下面综合上述3种架构的定义，统一了服务的概念。
对于服务的总的共性定义为：服务是通过提供有规范契约的接口、能够带来实用价值的一种有形组件或逻辑表示。
从上面的定义中，可以看出服务的基本共性：
1）服务能够带来实用价值。
2）服务必须具备有形组件或者逻辑表示，封装并且有显式边界。
3）服务需要提供接口并有接口契约。
下面分别解释这3个基本特性。首先，如果服务不能带来价值，就无所谓是否存在，也就没有必要对其进行定义，所以说价值是服务存在的根本；其次，要表示服务，必须有一定的承载物，在概念模型中，服务可以通过一种逻辑活动来说明。在物理模型中，服务以组件的形式表现出来，也许是软件组件，也许是硬件组件；最后，服务提供功能的方式是通过接口模式。外部环境通过接口可以访问或调用，实现服务提供的功能。服务的定义可以延伸和发展，具体的架构可以继承服务的基本概念。各个架构模型的服务继承关系如图2-1所示。
在继承图中，各个子服务都继承父服务的属性。故所有的服务都具有上述3个基本特征。下面会逐步描述这些服务的内容。比如微服务包括技术微服务和业务微服务，SOA服务则包含交互服务、流程服务、信息服务、基础服务和集成服务等。企业架构的服务类型包括有业务服务、应用服务和技术服务等。图2-1 服务概念继承关系图
服务是一个自包含的、无状态的实体，可以由多个组件组成。它通过事先定义的界面响应服务请求，可以执行诸如编辑和处理事务等离散性任务。服务本身并不依赖于其他函数和过程的状态。用什么技术实现服务，并不在其定义中加以限制。
2.服务的表现形式和组成
服务有两种表现形式：对于抽象业务而言，服务表现为一种功能的描述，这种是概念上的服务；对于实在运行而言，服务是一个封装的有形组件，包含了契约和实现。
要了解服务的组成，首先要定义一个原子服务。所谓原子服务，就是某项服务无法再继续分解的最小单元，相当于人体的细胞。原子服务由4部分组成：1）一个与业务功能或者业务数据相关的接口；2）原子服务需要依赖的外部服务；3）约束这个接口契约的服务合约；4）具体的服务实现模块。如图2-2所示。图2-2 原子服务的构成
原子服务的构成模块及其内容说明见表2-1。表2-1 原子服务的构成模块及其功能描述
原子服务有点类似于服务组件架构（Service Component Architecture，SCA）的SCA组件。SCA是IBM提出的一种编程模型，支持基于SOA的应用程序实现，支持实现服务组件的各种技术，以及连接服务组件的各种存取方法。SCA服务的组件构成如图2-3所示。图2-3 SCA服务的组件构成图
服务组件是SCA中的基本组成元素和基本构建单位，也是具体实现业务逻辑的地方。表2-2描述了服务组成的各个部分。表2-2 SCA服务的构成模块及其功能描述
图2-4是组件（Component）通过连接形成SCA构件，左边的服务（Service）是两个组件连接起来后经过提升后对外提供的服务，右边的引用（Reference）是提升后对外的依赖，外界可以通过设置属性（Property）来改变构件的行为。
2.1.2 SOA架构的服务概念
1.SOA服务定义
在微服务架构没有出现之前，服务基本上都是基于SOA架构的服务。所以SOA服务有一定的普遍性。图2-4 SCA的服务组件组装模型
在The Open Group组织的定义中，SOA服务是一个重复业务活动的逻辑表示。
在维基百科关于 SOA 的服务定义中，服务是一个独立的功能单元，可以远程访问、独立操作和更新。维基百科还定义了服务的4个属性：1）它在逻辑上表示具有指定结果的业务活动；2）它是独立的；3）对于消费者来说，它是一个黑匣子；4）它可能包括其他基础服务。
根据SOA的许多定义，我们归纳了一下SOA服务的概念：它是一个抽象物，可重用，无状态，其封装了高级业务内容，隐藏内部实现细节，只提供实现的功能说明。SOA 服务不依赖特定的技术或框架，只受制于一定的约束条件及服务规约，具有中立性，其本质是屏蔽应用间复杂的业务或技术逻辑。
2.SOA服务的特征
SOA服务具有以下5个特征。
■ 可重用——一个服务可以被多个应用和业务流程调用。
■ 松耦合——服务请求者到服务提供者的绑定与服务之间应该是松耦合的。
■ 明确定义的接口——服务交互必须是明确定义的。一些服务描述语言主要用于描述服务请求者所要求的绑定到服务提供者的细节。
■ 无状态的服务设计——服务应该是独立的、自包含的请求，在实现时它不需要获取从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当产生依赖时，它们可以定义成通用业务流程、函数和数据模型。
■ 基于开放标准——当前SOA的实现形式是Web服务，基于的是公开的W3C及其他公认标准，采用第一代Web服务定义的SOAP、WSDL和UDDI以及第二代Web服务定义的WS-*来实现SOA。
2.1.3 微服务架构的服务概念
1.微服务定义
Martin Fowler和James Lewis并没有对微服务进行定义，而只是描述了微服务架构（Microservice Architectural Style）的一些设计模式、实现手段和管理方式。
Sam Newman在其图书《微服务设计》中给微服务下了一个定义，即微服务就是一些协同工作的小而自治的服务。
Garter的微服务定义为：微服务是一种严格限界、高度封装、松散耦合、支持独立部署和独立扩展的应用组件。在这里，微服务是一个软件组件。
维基百科是这样定义微服务的：微服务是一种软件开发技术，是 SOA 体系结构的一种变体，它将应用程序构造为松散耦合的服务集合。在微服务架构中，服务是细粒度的，协议是轻量级的。将应用程序分解成不同的小型服务的好处在于，它提高了模块化程度，使应用程序更易于理解、开发、测试，且对体系结构侵蚀有更强的弹性，进而独立开展各自的服务。它还允许通过连续重构来形成单个服务的体系结构。基于微服务的体系结构能够实现连续交付和部署。在这里，微服务变成了一个软件开发技术。
在百度百科中是这样描述微服务的：微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个支持的微服务。微服务策略可以让工作变得更为简便，它可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。在这里，微服务又成了一种软件架构。
目前在IT行业中还没有关于微服务的共识定义，同时也缺少官方共识。但微服务有着非常多的标签和说明，如微服务规模比较小，具有技术异构性，不依赖于任何开发编程语言和软件框架，拥有轻量级通信、轻量级协议、契约接口，采用去中心化模式，自治且能独立部署，容易替换和更新，围绕着实现功能进行组织设计，独立于基础设施环境等。
基于上述标签，可以这样定义微服务。从广义上理解，其涵盖了整个微服务领域，即所有关于微服务的事宜，这是一个概称，如同谈到大数据时就覆盖了关于大数据的所有一切。从狭义上来讲，微服务又有两个含义：第一个含义是按照字面解释，仅仅是一个服务，微小、独立、自治；第二个含义是指微服务架构，包括微服务本身和微服务的环境。
微服务有3个特征：1）提供一定功能价值的服务；2）颗粒度不大；3）有自治管理能力。
2.微服务类型
微服务主要有技术微服务和业务微服务两大类。技术微服务是一种在技术层面上提供服务的微服务类型，其具体的表现形式有文件微服务、缓存微服务、分布式微服务、目录微服务、数据存储微服务、消息微服务、安全微服务、认证微服务等；业务微服务是针对解决具体业务应用问题而把各个业务组件封装成微服务的类型。业务微服务的具体表现形式有用户权限微服务、支付微服务、交易微服务、订单微服务等。
2.1.4 企业架构的服务概念
按照TOGAT架构框架定义，企业架构主要包括业务架构、应用架构和技术架构。在基于服务的模式描述下，业务架构围绕着业务服务来构建业务组件、业务功能模块、业务接口等。应用架构围绕着应用服务来形成应用接口、应用组件、应用功能等。技术架构基于技术服务来形成技术组件、技术接口、节点等。
ArchiMate 模型有3种服务类型，分别是业务服务、应用服务和技术服务，如图2-5所示。下面是这几种服务的概念。图2-5 ArchiMate模型的服务映射图
■ 业务服务——显式定义的暴露业务行为。业务服务将业务角色或业务合作集合的功能提供给外界，并且对这些功能的访问需要通过各种业务接口，而这些功能的实现则是由各业务角色或业务合作集合执行的一个或多个业务流程、业务功能或业务协作来完成的。业务服务可以被业务流程、业务功能和业务交互使用。业务流程、业务功能和业务交互可以实现业务服务。业务接口或应用接口可以被指派给业务服务，用于表示业务服务的访问方式。
■ 应用服务——显式定义的公开应用程序行为。站在外部环境的角度来看，应用服务必须对用户提供有价值的功能。对于企业内部来说，应用服务也应该是业务相关的，可以被业务流程、业务功能、业务交互或应用功能使用。
■ 技术服务——一种显式定义的暴露技术行为。技术服务可以服务应用组件或节点。技术服务是通过技术功能或过程实现的，通过向节点分配技术接口，由节点公开，可以访问工件，可以由子服务组成。2.2 微服务架构和SOA架构
2.2.1 SOA架构概念
1.SOA架构定义
面向服务架构（SOA）又称“面向服务的体系结构”，是Gartner于1996年提出的概念。2002年 l2月，SOA 成了“现代应用开发领域最重要的课题”，国内外计算机专家、学者开始了对SOA的积极研究与探索。但是关于SOA架构，目前尚未有一个统一的、业界广泛接受的定义。
Gartner将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA 与大多数通用的客户端/服务器模型的不同之处在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”
维基百科对SOA架构的定义是：SOA是一种软件设计风格，在该架构中应用程序组件通过网络之间的通信协议向其他组件提供服务。SOA 架构的基本原则独立于供应商、产品和技术。
W3C将SOA定义为：一套可以被调用的组件，用户可以发布并发现其接口。
综上所述，SOA 是一种软件架构模式，架构将不同功能单元——服务（service），通过服务间定义良好的、中立的接口和契约联系起来。服务之间可以使用统一和标准的方式进行通信并形成松耦合。架构的基本原则是独立于具体实现服务的硬件平台、软件框架和编程语言。
SOA架构具有5个特征：
1）SOA架构是一种软件系统架构。SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构。它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它其实更像一种架构模式（Pattern），是一种理念架构，是人们面向应用服务的解决方案框架。
2）服务是整个SOA架构的核心。SOA架构的基本元素是服务，SOA 指定一组实体（服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约），这些实体详细说明了如何提供和消费服务。遵循 SOA 架构的应用系统必须有服务，这些服务是可互操作的（Interoperability）、自治的（Autonomous）、无状态的、重用的（Reuse）、位置透明的（Location Transparency）、松耦合的（Loosly Coupled）、封装的（Encapsulation），并且是粗粒度的。服务的互操作是指在 SOA 架构中，通过服务之间既定的通信协议进行互操作；主要有同步和异步两种通信机制。SOA 提供服务的互操作特性更有利于其在多种场合被重用；服务的自治功能是指由组件组成的组合模块，具有自包含和模块化特性。SOA非常强调架构中提供服务的功能实体的完全独立自主能力、自我管理和恢复能力；服务的无状态性是指，服务能够独立于具体实现，也不需要依靠其他服务的前后关系和状态。当出现了新的一个业务需求时，该服务可以很容易地纳入新的业务架构；服务的重用性可以降成本。这需要服务工作在特定处理过程的上下文中，独立于底层实现和客户需求的变更；服务的位置透明性是指，服务是针对业务需求设计的，需要反映需求的变化，即所谓敏捷（agility）设计。要想真正实现业务与服务的分离，就必须使得服务的设计和部署对用户来说是完全透明的；服务的封装性是将服务封装成用于业务流程的可重用组件。封装隐藏了复杂性，服务的API保持不变，使得用户远离具体实施上的变更；粗粒度服务提供的服务具有高层次的业务逻辑。可以组合细粒度的服务，形成新的商业逻辑，它具有保证异构平台下可以用统一的方式使用服务、不需要多次往返于服务使用者和提供者的优点。
3）采用标准化的接口，面向服务划分系统——服务描述中的重点是交互时的操作，比如服务，调用操作的消息、消息的细节以及消息的细节向何处发送。SOA 通过标准化的接口，使得任何平台和用户都可以使用该服务。将庞大的业务系统拆分成高内聚的服务单元，每个单元对外提供服务能力，服务与服务之间通过相互协作共同实现业务价值。
4）松耦合——SOA框架中可以应用多种技术，服务消费者不依赖于服务提供者的技术实现（比如 Java 服务提供者，Python 服务消费者），双方可以通过 thrift、proto-buffer或者消息队列等框架来实现消息的互通。松散耦合指的是在实现服务和使用服务之间保持相对独立的关系，即对服务的实现进行修改不会影响使用者。服务的松耦合度是指服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台等。在一个极端的情况下，服务提供者可以将以前基于遗留代码（如COBOL）的实现完全用基于Java语言的新代码取代，同时又不对服务请求者造成任何影响。这种应用场景是真实存在的，只要新代码支持相同的通信协议。
2.SOA 体系和环境
SOA 的体系结构如图2-6所示，在 SOA 中包含3种不同的角色。
1）服务使用者是能够使用服务的实体，它既可以是应用程序，也可以是软件模块或服务。
2）服务提供者是主要完成新服务的创建和注册的实体，同时生成接口文件，并且会发布自己的服务接口和相关信息。
3）服务注册中心是服务发现的支持者，包括服务信息库，并且允许使用者在这里查询提供者发布的所有接口信息。
三者之间的关系是，服务使用者从服务提供者处了解相关 Web 服务的功能描述，从服务注册的信息库中能够查询 Web 服务的具体信息，然后调用和绑定服务提供者。
在具体环境中各程序可以同时充当各个实体的角色，它们之间的互相通信操作包括3种：1）发布。为了访问某个服务，需要通过发布相应的服务描述便于使用者发现并绑定调用；2）发现。通过查找服务的注册表确定符合标准的服务；3）绑定和调用。检索到了服务的描述之后，使用者按照服务的描述调用绑定相应的服务。图2-6 SOA 体系结构
SOA 中的构件主要包括服务组件和服务环境。1）服务组件：实现服务描述中的接口组件是 SOA 实现的核心。软件组件、组合的服务或者是实现了接口描述的相关编码都可被认为是服务组件；2）服务环境：定义使用者与提供者交互的方法、接口规范格式以及来自服务的请求与响应的格式以及相关的支撑环境。
从 SOA 的构成可以看出，如果可以用良好的机制来封装应用，单个应用就能组合为一个大的服务集群，并且封装的过程已经屏蔽了程序中大量复杂的细节，仅提供相关的接口内容。
2.2.2 微服务架构定义
微服务自2014年首次提出后，很多大型公司都已经开始实践并使用微服务来完成公司的主要业务逻辑，比如谷歌、亚马逊、Twitter。一般而言，微服务架构是一种低耦合的软件架构，首先将软件系统拆分成多个独立且可扩展的服务，使用一套小服务来开发单个应用，每个服务运行在自己的进程中，只负责完成特定的任务，并使用轻量级机制通信，通常是HTTP API，最后集成每个服务完成最终业务的系统。
目前对于微服务架构并没有官方（或国际标准）的定义。归纳和总结大师Martin Fowler和 James Lewis也没有对微服务架构模式给出精确的定义，只是在设计思想上给出了一些指导方针。他们认为，微服务架构构建的是一种基于业务能力的服务，这些服务能够通过自动化部署机制来独立部署，具有终端智能化而通信渠道弱化的特点，这些服务使用不同的编程语言以及不同数据存储技术，并保持最低限度的集中式管理。仔细分析可以发现，上述表述只是客观地描述了一种软件实现的现象，并不是一个完整的定义。
Garter认为，微服务架构是一种可供开发人员实施微服务及微服务应用的设计范例。微服务基础架构包含不同类型的应用基础架构技术，能够促进微服务及微服务应用的开发、测试、封装、部署、运行、监控和管理。
还有这样定义的：微服务设计就是将一个应用程序封装成一系列微小的服务，每个服务运行在各自的进程中，并采用轻量级机制来交互通信。这些服务都围绕着业务能力来实现，并由自动部署工具来完成服务的部署上线。微服务架构不同于传统 Web 应用架构，它将应用程序拆分成多个独立且易于扩展的服务，每个服务负责完成一个小的模块，容易实现敏捷开发和快速部署。
综上所述，可以这样定义微服务架构（Microservices Architectures，MSA），微服务架构将应用程序的不同功能单元微服务（Microservice）化，通过微服务间定义良好的接口和契约（Contract）联系起来。接口采用中立的方式定义，独立于具体实现服务的操作系统、软件框架、编程语言和运行基础设施平台，可以使用统一的、标准的、轻量级的方式进行通信。这种具有中立接口的定义的特征被称为服务之间的松耦合。同时支持敏捷和自动化的设计、开发、测试、封装、部署、运行、监控和管理。
从这个定义中，可以看到下面4个特点。
■ 微服务架构是一种软件系统架构。微服务架构既不是一种具体的IT技术，也不是一种软件框架，更不是一种产品，而是一种软件系统架构。从这个角度上来说，它其实更像一种架构模式（Pattern），是一种理念架构，是面向应用系统的解决方案。
■ 微服务是整个微服务架构实现的核心。微服务架构的基本元素是微服务，微服务架构指定一组实体，这些实体详细说明了如何提供和消费服务。这些实体是规模小的、技术可互操作的、独立的、模块化的、位置明确的、松耦合的，并且可以通过网络查找其地址。
■ 实现微服务架构需要基础环境。微服务架构一定有一个微服务基础运行平台作为支撑环境，而微服务框架平台可以统一完成，也可以分别组合。微服务框架需要支持服务注册、服务发现、共享配置存储、验证和授权、请求路由、负载平衡、通信稳定性，以及服务监控等基础功能。
■ 基础设施自动化。微服务架构覆盖设计、开发、测试、封装、部署、运行、监控和管理等阶段，容易实现敏捷开发和快速部署。
2.2.3 微服务架构和SOA架构的比较
当比较微服务架构和 SOA 架构时，很难达成一致意见。有人认
试读结束[说明：试读内容隐藏了图片]