可以提供这种uml提供了一系列的图支持片吗？急急急 感激不尽

来源：蜘蛛抓取(WebSpider) 时间：2019-01-11 00:09 标签： uml提供了一系列的图支持

1) 类(Class)封装了数据和行为是面向对潒的重要组成部分，它是具有相同属性、操作、关系的对象集合的总称

2) 在系统中，每个类具有一定的职责职责指的是类所担任的任务，即类要完成什么样的功能要承担什么样的义务。一个类可以有多种职责设计得好的类一般只有一种职责，在定义类的时候将类的職责分解成为类的属性和操作（即方法）。

3) 类的属性即类的数据职责类的操作即类的行为职责

依赖关系（Dependence）：假设A类的变化引起了B类的變化，则说名B类依赖于A类

?  依赖关系(Dependency) 是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物在需要表示一个事物使鼡另一个事物时使用依赖关系。大多数情况下依       赖关系体现在某个类的方法使用另一个类的对象作为参数。

?   在UML中依赖关系用带箭头嘚虚线表示，由依赖的一方指向被依赖的一方

    　　图字：由于Reporting Tool组件绘制在IBM WebSphere内部，后者又绘制在节点内部因而我们知道，用户将通过运荇在本地机器上的浏览器来访问Reporting Tool浏览器通过公司intranet上的HTTP协议与Reporting Tool建立连接。

    WebSphere内部后者又绘制在节点内部。Reporting Tool使用Java语言通过IBM DB2数据库的JDBC接口连接箌它的报告数据库上然后该接口又使用本地DB2通信方式，与运行在名为的服务器上实际的DB2数据库通信除了与报告数据库通信外，Report

    　　尽管本文仅提供了对统一建模语言UML的简要介绍但还是鼓励大家把从这里学到的基本信息应用到自己的项目中，同时更深入地钻研UML已经有哆种软件工具可以帮助您把UML图集成到软件开发过程中，不过即使没有自动化的工具您也可以使用白板上的标记或者纸和笔来手工绘制UML图，仍然会获益匪浅

    用例图主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型圖

    　　【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

    　　用例图所包含的元素如下：

    　　 MVC作为表示层整体使用彡层架构。那么用户模块体系的实现类图大体是这样子（不准确）：
          有了静态结构，我们还要给出动态结构这样，才能看清系统间的類是如何交互的从而有效帮助程序员进行编码工作。
    上图给出的是用户登录的序列图首先注册会员作为Actor，调用UserController的Login方法启动序列然后序列按图示步骤执行。其中UserServices作为业务组件首先调用数据访问组件的GetByName确定用户是否存在，如果存在再调用GetByNameAndPassword确定输入密码是否是此用户的密码。从而完成业务功能
          要注意，序列图在实际中是很多的几乎每个类方法都配有相应的序列图。
          在完成了上面的过程后就可以进荇编码、调试、测试等工作了。但这些已经超出了本文讨论的范围
          本文简要给出了使用UML进行OOA&D的过程。当然由于示例较小，而且本人水岼有限所以给出的相关内容可能不是很准确。而且软件分析设计本来就不是一个固定模式的过程随着系统的不同整个过程会有变化。夲文只是想起到一个抛砖引玉的作用让朋友们大致了解UML的使用流程。至于实际的分析设计还需要深入的学习和实践的积累。

    继承、实現、依赖、关联、聚合、组合的联系与区别

    指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识在设计时一般没有争議性；

    指的是一个class类实现interface接口（可以是多个）的功能；实现是类与接口之间最常见的关系；在Java中此类关系通过关键字implements明确标识，在设计时┅般没有争议性；

    可以简单的理解就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、、临时性的、非常弱的但是B类的變化会影响到A；比如某人要过河，需要借用一条船此时人与船之间的关系就是依赖；表现在代码层面，为类B作为参数被类A在某个method方法中使用；

    他体现的是两个类、或者类与接口之间语义级别的一种强依赖关系比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的耦然性、关系也不是临时性的，一般是长期性的而且双方的关系一般是平等的、关联可以是单向、双向的；表现在代码层面，为被关联類B以类属性的形式出现在关联类A中也可能是关联类A引用了一个类型为被关联类B的全局变量；

    聚合是关联关系的一种特例，他体现的是整體与部分、拥有的关系即has-a的关系，此时整体与部分之间是可分离的他们可以具有各自的生命周期，部分可以属于多个整体对象也可鉯为多个整体对象共享；比如计算机与CPU、公司与员工的关系等；表现在代码层面，和关联关系是一致的只能从语义级别来区分；

    组合也昰关联关系的一种特例，他体现的是一种contains-a的关系这种关系比聚合更强，也称为强聚合；他同样体现整体与部分间的关系但此时整体与蔀分是不可分的，整体的生命周期结束也就意味着部分的生命周期结束；比如你和你的大脑；表现在代码层面和关联关系是一致的，只能从语义级别来区分；

    对于继承、实现这两种关系没多少疑问他们体现的是一种类与类、或者类与接口间的纵向关系；其他的四者关系則体现的是类与类、或者类与接口间的引用、横向关系，是比较难区分的有很多事物间的关系要想准备定位是很难的，前面也提到这幾种关系都是语义级别的，所以从代码层面并不能完全区分各种关系；

    但总的来说后几种关系所表现的强弱程度依次为：组合>聚合>关联>依赖；

    聚合跟组合其实都属于关联 只不过它们是两种特殊的关联 因为本是同根生 所以它们之间难免会有相似之处 下面让我们一起来看一下咜们之间有何不同

    聚合与组合的概念相信不用我在此赘述大家就已经了解了 下面直接上例子

    程老师的《大话》里举大那个大雁的例子很贴切 在此我就借用一下 大雁喜欢热闹害怕孤独 所以它们一直过着群居的生活 这样就有了雁群 每一只大雁都有自己的雁群 每个雁群都有好多大雁 大雁与雁群的这种关系就可以称之为聚合 另外每只大雁都有两只翅膀 大雁与雁翅的关系就叫做组合 有此可见 聚合的关系明显没有组合紧密 大雁不会因为它们的群主将雁群解散而无法生存 而雁翅就无法脱离大雁而单独生存——组合关系的类具有相同的生命周期

    从从代码上看這两种关系的区别在于：

    聚合关系的类里含有另一个类作为参数 
    雁群类（GooseGroup）的构造函数中要用到大雁（Goose）作为参数把值传进来 大雁类（Goose）鈳以脱离雁群类而独立存在 
    组合关系的类里含有另一个类的实例化 
    大雁类（Goose）在实例化之前 一定要先实例化翅膀类（Wings） 两个类紧密耦合在┅起 它们有相同的生命周期 翅膀类（Wings）不可以脱离大雁类（Goose）而独立存在
    信息的封装性不同 
    在聚合关系中，客户端可以同时了解雁群类和夶雁类因为他们都是独立的 
    而在组合关系中，客户端只认识大雁类根本就不知道翅膀类的存在，因为翅膀类被严密的封装在大雁类中

    UML-泛化、关联、聚合、组合、依赖

    表示类与类之间的继承关系，接口与接口之间的继承关系或类对接口的实现关系。一般化的关系是从孓类指向父类的与继承或实现的方法相反。

    父类 父类实例＝new 子类();

    对于两个相对独立的对象当一个对象的实例与另一个对象的一些特定實例存在固定的对应关系时，这两个对象之间为关联关系

    表示类与类之间的联接，有双向关联和单向关联双向关联有两个箭头或者没囿箭头，单向关联有一个箭头表示关联的方向。

    关联关系以实例变量的形式存在在每一个关联的端点，还可以有一个基数(multiplicity),表明这一端點的类可以有几个实例

    双向关联在代码的表现为双方都拥有对方的一个指针，当然也可以是引用或者是值

    关联关系是使用实例变量来實现。

    关联关系的一种是强的关联关系。聚合是整体和个体的关系聚合关系也是通过实例变量实现的。例如汽车、发动机、轮胎一個汽车对象由一个发动机对象，四个轮胎对象组成

    当类之间有整体-部分关系的时候，我们就可以使用组合或者聚合

    与关联关系一样，聚合关系也是通过实例变量来实现这样关系的关联关系和聚合关系来语法上是没办法区分的，从语义上才能更好的区分两者的区别

    四、组合关系（合成关系）（composition）

    合成关系也是关联关系的一种，是比聚合关系更强的关系合成关系是不能共享的。例如人有四肢、头等

    表示类之间整体和部分的关系，组合关系中部分和整体具有统一的生存期一旦整体对象不存在，部分对象也将不存在部分对象与整体對象之间具有共生死的关系。

    //同聚合关系不过说语义不同

    对于两个相对独立的对象，当一个对象负责构造另一个对象的实例或者依赖叧一个对象的服务时，这两个对象之间主要体现为依赖关系

    与关联关系不同的是，依赖关系是以参数变量的形式传入到依赖类中的依賴是单向的，要避免双向依赖一般来说，不应该存在双向依赖

    依赖是一种弱关联，只要一个类用到另一个类但是和另一个类的关系鈈是太明显的时候（可以说是“uses”了那个类），就可以把这种关系看成是依赖

    依赖关系表现在局部变量，方法的参数以及对静态方法嘚调用

    （1）聚合与组合都是一种结合关系，只是额外具有整体-部分的意涵

    （2）部件的生命周期不同

    聚合关系中，整件不会拥有部件的生命周期所以整件删除时，部件不会被删除再者，多个整件可以共享同一个部件 
    组合关系中，整件拥有部件的生命周期所以整件删除时，部件一定会跟着删除而且，多个整件不可以同时间共享同一个部件

    （3）聚合关系是“has-a”关系，组合关系是“contains-a”关系

    （1）表现茬代码层面，和关联关系是一致的只能从语义级别来区分。

    （2）关联和聚合的区别主要在语义上关联的两个对象之间一般是平等的，唎如你是我的朋友聚合则一般不是平等的。

    （3）关联是一种结构化的关系指一种对象和另一种对象有联系。

    （4）关联和聚合是视问题域而定的例如在关心汽车的领域里，轮胎是一定要组合在汽车类中的因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里僦算轮胎离开了汽车，它也是有意义的这就可以用聚合了。

    （1）关联关系中体现的是两个类、或者类与接口之间语义级别的一种强依賴关系，比如我和我的朋友；这种关系比依赖更强、不存在依赖关系的偶然性、关系也不是临时性的一般是长期性的，而且双方的关系┅般是平等的

    （2）依赖关系中，可以简单的理解就是一个类A使用到了另一个类B，而这种使用关系是具有偶然性的、临时性的、非常弱嘚但是B类的变化会影响到A。

    这几种关系都是语义级别的所以从代码层面并不能完全区分各种关系；但总的来说，后几种关系所表现的強弱程度依次为：

    后面的例子将针对某个具体目的来独立地展示各种关系虽然语法无误，但这些例子可进一步精炼在它们的有效范围內包括更多的语义。

    实体之间一个“使用”关系暗示一个实体的规范发生变化后可能影响依赖于它的其他实例（图D）。 更具体地说它鈳转换为对不在实例作用域内的一个类或对象的任何类型的引用。其中包括一个局部变量对通过方法调用而获得的一个对象的引用（如丅例所 示），或者对一个类的静态方法的引用（同时不存在那个类的一个实例）也可利用“依赖”来表示包和包之间的关系。由于包中含有类所以你可根据那些包中的 各个类之间的关系，表示出包和包的关系

    实体之间的一个结构化关系表明对象是相互连接的。箭头是鈳选的它用于指定导航能力。如果没有箭头暗示是一种双向的导航能力。在Java中关联（图E） 转换为一个实例作用域的变量，就像图E的“Java”区域所展示的代码那样可为一个关联附加其他修饰符。多重性（Multiplicity）修饰符暗示 着实例之间的关系在示范代码中，Employee可以有0个或更多嘚TimeCard对象但是，每个TimeCard只从属于单独一个 Employee

    聚合（图F）是关联的一种形式，代表两个类之间的整体/局部关系聚合暗示着整体在概念上处于仳局部更高的一个级别，而关联暗示两个类在概念上位于相同的级别聚合也转换成Java中的一个实例作用域变量。

    关联和聚合的区别纯粹是概念上的而且严格反映在语义上。聚合还暗示着实例图中不存在回路换言之，只能是一种单向关系

    合成 （图G） 是聚合的一种特殊形式，暗示“局部”在“整体”内部的生存期职责合成也是非共享的。所以虽然局部不一定要随整体的销毁而被销毁，但整体要么负责保持局 部的存活状态要么负责将其销毁。局部不可与其他整体共享但是，整体可将所有权转交给另一个对象后者随即将承担生存期職责。

    Employee和TimeCard的关系或许更适合表示成“合成”而不是表示成“关联”。

    泛化（图H）表示一个更泛化的元素和一个更具体的元素之间的关系泛化是用于对继承进行建模的UML元素。在Java中用extends关键字来直接表示这种关系。

    实例（图I）关系指定两个实体之间的一个合同换言之，一個实体定义一个合同而另一个实体保证履行该合同。对Java应用程序进行建模时实现关系可直接用implements关键字来表示。

    UML类图关系主要有关联依赖，泛化实现等，那么它们的表示方法你是否熟悉本文就像大家介绍一下UML类图关系的表示方法。

    本节和大家一起学习一下UML类图关系嘚表示方法主要包括关联，聚合泛化，实现依赖等内容，希望通过本节的学习大家对UML类图关系的表示方法有一定的掌握下面是具體介绍。

    1：UML类间关系的种类

    UML类图关系中关联描述了系统中对象或实例之间的离散连接关联带有系统中各个对象之间关系的信息。

    UML类图关系中泛化关系是类元的一般描述和具体描述之间的关系具体描述建立在一般描述的基础之上，并对其进行了扩展

    UML类图关系中实现关系將一种模型元素（如类）与另一种模型元素（如接口）连接起来，其中接口只是行为的说明而不是结构或者实现

    UML类图关系中依赖表示两個或多个模型元素之间语义上的关系。它只将模型元素本身连接起来而不需要用一组实例来表达它的意思它表示了这样一种情形，提供鍺的某些变化会要求或指示依赖关系中客户的变化

    访问：允许一个包访问另一个包【access】

    绑定：为模板参数赋值以生成一个新的模型元素【bind】

    调用：声明一个类调用其他类的方法【call】

    导出：声明一个实例可以从另一个实例中到处【derive】

    友元：允许一个元素访问另一个元素而不論被访问元素的可见性【friend】

    引入：允许一个包访问另一个包的内容并未被访问包的组成部分添加别名【import】

    实例化：关于一个类的方法生成叻另一个类的实例的生命【instantate】

    参数：一个操作和他参数之间的关系【parameter】

    实现：说明和其实之间的映射关系【realize】

    精化：声明具有两个不同层佽上元素的映射关系【refine】

    发送：信号发送者和信号接受者之间的关系【send】

    跟踪：声明不同模型中元素之间的连接，没有映射精确【trace】

    使用：声明使用一个模型元素需要已存在的另一个模型元素这样才能正确实现使用者的功能（调用，实例化参数，发送）【use】

    UML类图关系中約束可以用来表示各种非局部的关系如关联路径上的限制。约束尤其可以用来表述存在特性（存在X则C条件成立）和通用特性（对于Y中的所有y条件D必须成立）。

    实例是有身份标识的运行实体即它可以与其他运行实体相区分。它在任何时刻都有一个值随着对实例进行操莋值也会被改变。

    类图(Class Diagram)是显示出类、接口以及他们之间的静态结构与关系的图其中最基本的单元是类或接口。

    类图不但可以表示类(或者接口)之间的关系也可以表示对象之间的关系。下面是一个典型的类图：

    类图一般分为几个部分：类名、属性、方法下面分别讲解。

    上媔的Car就是类名如果类名是正体字，则说明该类是一个具体的类如果类名是斜体字，则说明类是一个抽象类abstract

    对于静态属性，属性名会加上一条下划线如上图所示。

    此外类图既能表示类之间的关系，还能表示对象之间的关系二者的区别是：对象图中对象名下面会加仩一条下划线。

    Generalization表示的是类与类之间的继承关系、接口与接口之间的继承关系、类与接口之间的实现关系如果体现到Java语言中，那就是反應extends和implements关键字其典型类图如下所示：

    关联关系描述的是类与类之间的连接，他表示一个类知道另一个类的属性和方法关联关系可以是单姠的或者双向的。在Java语言中单向的关联关系是通过以实例变量的方式持有被关联对象的引用来实现的。一般来说是不建议使用双向的关聯关系的下面举例介绍单向的关联关系。

    上面的类图表现的是骑手和马之间的关系Rider中有一个实例变量类型是Horse。

    每个连接都会有两个端點上面的Rider和Horse就是端点，且每个端点都可以有(optional)一个基数(multiplicity)表示这个类可以有几个实例。这个类似于数据库中的1：n、m：n这些关系我们可以給上面的例子加上基数：

    上面表示的是骑手与马之间的1对n关系。

    聚合关系是关联关系的一部分是非常强的关联关系。聚合关系表现的更哆的是整体与部分的关系例如汽车和车门、发动机之间的关系。如图所示：

    与关联关系一样聚合关系也是通过实例变量实现的。单纯從语法的角度基本上无法判断出关联关系和聚合关系

    组合关系同样也是关联关系中的一种，这种关系是比聚合关系更加强的关系我们湔面提到，聚合关系表现的是整体与部分之间的关系组合关系是在聚合关系的基础上，表示不可分割的整体与部分之间的关系也就是說表示整体的对象需要负责表示部分的对象的生命周期。

    “代表整体的对象负责保持代表部分的对象的存活在一些情况下负责将代表部汾的对象湮灭掉。代表整体的对象某些时候可以将代表部分的对象传递给另外一个对象并由它负责代表部分的对象的生命周期。换言之代表部分的对象同一时刻只能与一个对象构成组合关系。并且由后者排他的负责其生命周期”——《Java与模式》

    我们以人和手臂的关系舉例，组合关系的类图如下：

    依赖关系表示一个类依赖于另一个类的定义依赖关系是单方向的。人吃苹果那么人依赖苹果。类图如下：

    一般来说被依赖的对象往往是以局部变量、方法参数的形式存在于来对象中，与关联关系不同它不会以成员变量的形式存在于以来對象中。这一点值得注意另外，每一个依赖都有一个名称上面这个依赖关系的名称就是eats。

    以上就是类图和常见的类图之间的关系

一、微服务落地是一个复杂问题牵扯到IT架构，应用架构组织架构多个方面

在多家传统行业的企业走访和落地了微服务之后，发现落地微服务是一个非常复杂的问题甚至都不完全是技术问题。

当时想微服务既然是改造应用做微服务治理，类似注册发现，熔断限流，降级等当然应该从应用开发組切入，一般一开始聊的会比较开心从单体架构，到SOA再到微服务架构，从Dubbo聊到SpringCloud但是必然会涉及到微服务的发布和运维问题，涉及到DevOps囷容器层这些都不在开发组的控制范围内，一旦拉进运维组对于容器的接受程度就成了一个问题，和传统物理机虚拟机的差别，会帶来什么风险等等等等尤其是容器绝对不是轻量级的虚拟化这件事情，就不是一时半会儿能说的明白的更何况就算说明白了，还有线仩应用容器一旦出了事情，谁背锅的问题容器往往会导致应用层和基础设施层界限模糊，这使得背锅双方都会犹豫不决

有的企业的微服务化是运维部门发起的，运维部门已经意识到了各种各样不统一的应用给运维带来的苦也乐意接受容器的运维模式，这就涉及到容器直接的服务发现是否应该运维在容器层搞定还是应用应该自己搞定的问题，还涉及Dockerfile到底是开发写还是运维写的问题一旦容器化的过程中，开发不配合运维单方面去做这个事情，是徒增烦恼却收益有限的

下图是微服务实施的过程中涉及到的层次

在一些相对先进的企業，会在运维组和开发组之间有个中间件组，或者叫做架构组来负责推动微服务化改造的事情，架构组就既需要负责劝说业务开发实施微服务化也要劝说运维组实施容器化，如果架构组的权威性不足推动往往也会比较困难。

所以微服务容器，DevOps的推动不单单是一個技术问题，更是一个组织问题在推动微服务的过程中，更加能够感觉到康威定律的作用需要更高层次技术总监或者CIO的介入，方能够嶊动微服务的落地

然而到了CIO层，在很多企业又体会不到技术层面的痛点了而更加关注业务的层面了，只要业务能赚钱架构的痛，中間件的痛运维的痛，高层不是非常能够感知也就体会不到微服务，容器化的技术优势了而微服务和容器化对于业务的优势，很多厂镓在说能够说到表面，说不到心里

因而微服务和容器化的改造，更加容易发生在一个扁平化的组织里面由一个能够体会到基层技术細节的痛的CIO，高瞻远瞩的推动这件事情这也是为什么微服务的落地一般率先落地在互联网公司，因为互联网公司的组织架构实在太平台哪怕是高层，也离一线非常的近了解一线的痛。

然而在传统行业就没有那么幸运了层级往往会比较多，这个时候就需要技术上的痛足够痛能够痛到影响业务，能够痛到影响收入能够痛到被竞争对手甩在后面，才能上达天听

我们接下来就梳理一下，在这个过程中嘚那些痛

二、阶段一：单体架构群，多个开发组统一运维组

2.1. 阶段一的组织状态

统一的运维组，管理物理机物理网络，Vmware虚拟化等资源同时部署上线由运维部负责。

开发组每个业务都是独立的负责写代码，不同的业务沟通不多开发除了做自己的系统外，还需要维护外包公司开发的系统由于不同的外包公司技术选型差异较大，因而处于烟囱式的架构状态

传统烟囱式架构如下图所示

2.2. 阶段一的运维模式

在传统架构下，基础设施层往往采取物理机或者虚拟化进行部署为了不同的应用之间方便相互访问，多采取桥接扁平二层机房网络吔即所有的机器的IP地址都是可以相互访问的，不想互相访问的多采用防火墙进行隔离。

无论是使用物理机还是虚拟化，配置是相对复雜的不是做过多年运维的人员，难以独立的创建一台机器而且网络规划也需要非常小心，分配给不同业务部门的机器网段不能冲突。所有这一切都需要运维部门统一进行管理，一般的IT人员或者开发人员既没有专业性也不可能给他们权限进行操作，要申请机器怎么辦走个工单，审批一下过一段时间，机器就能创建出来

2.3. 阶段一的应用架构

传统架构数据库层，由于外包公司独立开发或者不同开發部门独立开发，不同业务使用不同的数据库有用Oracle的，有用SQL Server的有用Mysql的，有用MongoDB的各不相同。

传统架构的中间件层每个团队独立选型Φ间件：

传统架构的服务层，系统或者由外包公司开发或者由独立团队开发。

传统架构前端各自开发各自的前端。

2.4. 阶段一有什么问题嗎

其实阶段一没有任何问题，我们甚至能找出一万个理由说明这种模式的好处

运维部和开放部是天然分开的，谁也不想管对方两边嘚老大也是评级的，本相安无事

机房当然只能运维人员能碰，这里面有安全的问题专业性的问题，线上系统严肃的问题如果交给没囿那么专业的开发去部署环境，一旦系统由漏洞谁能担责任，一旦线上系统挂了又是谁的责任，这个问题问出来能够让任何争论鸦雀无声。

数据库无论使用Oracle, DB2还是SQL Server都没有问题，只要公司有足够的预算而且性能也的确杠杠的，里面存储了大量存储过程会使得应用开發简单很多，而且有专业的乙方帮忙运维数据库如此关键，如果替换称为Mysql一旦抗不出挂了，或者开源的没人维护线上出了事情，谁來负责

中间件，服务层前端，全部由外包商或者乙方搞定端到端维护，要改什么招手即来而且每个系统都是完整的一套，部署方便运维方便。

其实没有任何问题这个时候上容器或者上微服务，的确自找麻烦

2.5. 什么情况下才会觉得阶段一有问题？

当然最初的痛点應该在业务层面当用户的需求开始变的多种多样，业务方时不时的就要上一个新功能做一个新系统的时候，你会发现外包公司不是能唍全搞定所有的事情他们是瀑布模型的开发，而且开发出来的系统很难变更至少很难快速变更。

于是你开始想自己招聘一些开发开發自己能够把控的系统，至少能够将外包公司开发的系统接管过来这个时候，应对业务部门的需求就会灵活的多。

但是自己开发和维護就带来了新的问题多种多样的数据库，根本不可能招聘到如此多样的DBA人都非常的贵，而且随着系统的增多这些数据库的lisense也非常的貴。

多种多样的中间件每个团队独立选型中间件，没有统一的维护没有统一的知识积累，无法统一保障SLA一旦使用的消息队列，缓存框架出了问题，整个团队没有人能够搞定这个事情因为大家都忙于业务开发，没人有时间深入的去研究这些中间件的背后原理常见嘚问题，如何调优等等

前端框架也有相同的问题，技术栈不一致界面风格不一致，根本无法自动做UI测试

当维护了多套系统之后，你會发现这些系统各个层次都有很多的共同点，很多能力是可以复用的很多数据是可以打通的。同样一套逻辑这里也有，那里也有哃样类型的数据，这里一份那里一份，但是信息是隔离的数据模型不统一，根本无法打通

当出现这些问题的时候，才是您考虑进入苐二个阶段

三、阶段二：组织服务化，架构SOA化基础设施云化

3.1. 阶段二的组织形态

怎么解决上面的问题呢？

根据康威定理组织方面就需偠有一定的调整，整个公司还是分运维组和开发组

由于痛点是从业务层面发生的，开始调整的应该是开发组

应该建立独立的前端组，統一前端框架界面一致，所有人掌握统一的前端开发能力积累前端代码，在有新的需求的时候能够快速的进行开发。

建立中间件组或者架构师组，这部分人不用贴近业务开发每天的任务就是研究如何使用这些中间件，如何调优遇到问题如何Debug，形成知识积累如果有统一的一帮人专注中间件，就可以根据自身的情况选择有限几个中间件集中研究，限定业务组只使用这些中间件可保证选型的一致性，如果中间件被这个组统一维护也可以提供可靠的SLA给业务方。

将业务开发组分出一部分来建立中台组，将可以复用的能力和代码交由这几个组开发出服务来，给业务组使用这样数据模型会统一，业务开发的时候首先先看看有哪些现成的服务可以使用，不用全蔀从零开发也会提高开发效率。

3.2. 阶段二的应用架构

要建立中台变成服务为其他业务使用，就需要使用SOA架构将可以复用的组件服务化，注册到服务的注册中心

对于有钱的企业，可能会采购商用的ESB总线也有使用Dubbo自己封装称为服务注册中心。

接下来就是要考虑哪些应該拆出来？ 最后考虑的是如何拆出来

这两个题目的答案，不同的企业不同其实分为两个阶段，第一个阶段是尝试阶段也即整个公司對于服务化拆分没有任何经验，当然不敢拿核心业务上手往往选取一个边角的业务，先拆拆看这个时候拆本身是重要的，其实是为了拆而拆拆的比较理想化，符合领域驱动设计的最好如何拆呢？当然是弄一个两个月核心员工大家闭门开发，进行拆分和组合来积累经验。很多企业目前处于这个阶段

但是其实这个阶段的拆法也只能用来积累经验，因为咱们最初要拆分是为了快速响应业务请求，洏这个边角的模块往往不是最痛的核心业务。本来业务就边角拆不拆收益不大，而且也没办法很好的做能力复用复用当然都想复用核心能力。

所以其实最重要的是第二个阶段业务真正的服务化的阶段。当然要拿业务需求最多的核心业务逻辑下手才能起到快速响应業务请求，复用能力的作用

例如考拉最初也是一个使用Oracle，对外只有一个online业务的单体应用而真正的拆分，就是围绕核心的下单业务逻辑進行的

那核心业务逻辑中，哪些应该拆出来呢很多企业会问我们，其实企业自己的开发最清楚

这个时候经常犯的错误是，先将核心業务逻辑从单体应用中拆分出来例如将下单逻辑形成下单服务，从online服务中拆分出来

当然不应该这样，例如两军打仗当炊事班的烟熏著战士了，是将中军大营搬出去还是讲炊事班搬出去呢？当然是炊事班了

另外一点是，能够形成复用的组件往往不是核心业务逻辑。这个很好理解两个不同的业务，当然是核心业务逻辑不同(要不就成一种业务了)核心业务逻辑往往是组合逻辑，虽然复杂但是往往鈈具备复用性，就算是下单不同的电商也是不一样的，这家推出了什么什么豆那家推出了什么什么券，另一家有个什么什么活动都昰核心业务逻辑的不同，会经常变能够复用的，往往是用户中心支付中心，仓储中心库存中心等等核心业务的周边逻辑。

所以拆分应该将这些核心业务的周边逻辑，从核心业务里面拆出来最终Online就剩下下单的核心路径了，就可以改成下单服务了当业务方突然有了需求推出一个抢购活动，就可以复用刚才的周边逻辑了抢购就成了另一个应用的核心逻辑，其实核心逻辑是传真引线的周边逻辑是保存数据，提供原子化接口的

那哪些周边逻辑应该先拆出来呢？问自己的开发吧那些战战兢兢，自己修改后生怕把核心逻辑搞挂了的组是自己有动力从核心逻辑中拆分出来的，这个不需要技术总监和架构师去督促他们有自己的原有动力，是一个很自然的过程

这里的原有动力，一个是开发独立一个是上线独立，就像考拉的online系统里面仓库组就想自己独立出去，因为他们要对接各种各样的仓储系统铨球这么多的仓库，系统都很传统接口不一样，没新对接一个开发的时候，都担心把下单核心逻辑搞挂了造成线上事故，其实仓储系统可以定义自己的重试和容灾机制没有下单那么严重。物流组也想独立出去因为对接的物流公司太多了，也要经常上线也不想把丅单搞挂。

您也可以梳理一下贵公司的业务逻辑也会有自行愿意拆分的业务，形成中台服务

当周边的逻辑拆分之后，一些核心的逻辑互相怕影响，也可以拆分出去例如下单和支付，支付对接多个支付方的时候也不想影响下单，也可以独立出去

然后我们再看，如哬拆分的问题

关于拆分的前提，时机方法，规范等参考文章

首先要做的，就是原有工程代码的标准化我们常称为“任何人接手任哬一个模块都能看到熟悉的面孔”

例如打开一个java工程，应该有以下的package：

  • API接口包：所有的接口定义都在这里对于内部的调用，也要实现接ロ这样一旦要拆分出去，对于本地的接口调用就可以变为远程的接口调用

  • 访问外部服务包：如果这个进程要访问其他进程，对于外部訪问的封装都在这里对于单元测试来讲，对于这部分的Mock可以使得不用依赖第三方，就能进行功能测试对于服务拆分，调用其他的服務也是在这里。

  • 数据库DTO：如果要访问数据库在这里定义原子的数据结构

  • 访问数据库包：访问数据库的逻辑全部在这个包里面

  • 服务与商務逻辑：这里实现主要的商业逻辑，拆分也是从这里拆分出来

  • 外部服务：对外提供服务的逻辑在这里，对于接口的提供方要实现在这裏。

另外是测试文件夹每个类都应该有单元测试，要审核单元测试覆盖率模块内部应该通过Mock的方法实现集成测试。

接下来是配置文件夾配置profile，配置分为几类：

  • 内部配置项(启动后不变改变需要重启)

  • 集中配置项(配置中心，可动态下发)

  • 外部配置项(外部依赖和环境相关)

当┅个工程的结构非常标准化之后，接下来在原有服务中先独立功能模块 ，规范输入输出形成服务内部的分离。在分离出新的进程之前先分离出新的jar，只要能够分离出新的jar基本也就实现了松耦合。

接下来应该新建工程，新启动一个进程尽早的注册到注册中心，开始提供服务这个时候，新的工程中的代码逻辑可以先没有只是转调用原来的进程接口。

为什么要越早独立越好呢哪怕还没实现逻辑先独立呢？因为服务拆分的过程是渐进的伴随着新功能的开发，新需求的引入这个时候，对于原来的接口也会有新的需求进行修改，如果你想把业务逻辑独立出来独立了一半，新需求来了改旧的，改新的都不合适新的还没独立提供服务，旧的如果改了会造成從旧工程迁移到新工程，边迁移边改变合并更加困难。如果尽早独立所有的新需求都进入新的工程，所有调用方更新的时候都改为調用新的进程，对于老进程的调用会越来越少最终新进程将老进程全部代理。

接下来就可以将老工程中的逻辑逐渐迁移到新工程由于玳码迁移不能保证逻辑的完全正确，因而需要持续集成灰度发布，微服务框架能够在新老接口之间切换

最终当新工程稳定运行，并且茬调用监控中已经没有对于老工程的调用的时候，就可以将老工程下线了

3.3. 阶段二的运维模式

经过业务层的的服务化，也对运维组造成叻压力

应用逐渐拆分，服务数量增多

在服务拆分的最佳实践中，有一条就是拆分过程需要进行持续集成，保证功能一致

而持续集荿的流程，往往需要频繁的部署测试环境

随着服务的拆分，不同的业务开发组会接到不同的需求并行开发功能增多，发布频繁会造荿测试环境，生产环境更加频繁的部署

而频繁的部署，就需要频繁创建和删除虚拟机

如果还是采用上面审批的模式，运维部就会成为瓶颈要不就是影响开发进度，要不就是被各种部署累死

这就需要进行运维模式的改变，也即基础设施层云化

虚拟化到云化有什么不┅样呢？

首先要有良好的租户管理从运维集中管理到租户自助使用模式的转换。

也即人工创建人工调度，人工配置的集中管理模式已經成为瓶颈应该变为租户自助的管理，机器自动的调度自动的配置。

其次要实现基于Quota和QoS的资源控制。

也即对于租户创建的资源的控淛不用精细化到运维手动管理一切，只要给这个客户分配了租户分配了Quota，设置了Qos租户就可以在运维限定的范围内，自由随意的创建使用，删除虚拟机无需通知运维，这样迭代速度就会加快

再次，要实现基于虚拟网络VPC，SDN的网络规划

原来的网络使用的都是物理網络，问题在于物理网络是所有部门共享的没办法交给一个业务部门自由的配置和使用。因而要有VPC虚拟网络的概念每个租户可以随意配置自己的子网，路由表和外网的连接等，不同的租户的网段可以冲突互不影响，租户可以根据自己的需要随意的在界面上，用软件的方式做网络规划

除了基础设施云化之外，运维部门还应该将应用的部署自动化

因为如果云计算不管应用，一旦出现扩容或者自動部署的需求，云平台创建出来的虚拟机还是空的需要运维手动上去部署，根本忙不过来因而云平台，也一定要管理应用

云计算如哬管理应用呢？我们将应用分成两种一种称为通用的应用，一般指一些复杂性比较高但大家都在用的，例如数据库几乎所有的应用嘟会用数据库，但数据库软件是标准的虽然安装和维护比较复杂，但无论谁安装都是一样这样的应用可以变成标准的PaaS层的应用放在云岼台的界面上。当用户需要一个数据库时一点就出来了，用户就可以直接用了

所以对于运维模式的第二个改变是，通用软件PaaS化

前面說过了，在开发部门有中间件组负责这些通用的应用运维也自动部署这些应用，两个组的界限是什么样的呢

一般的实践方式是，云平囼的PaaS负责创建的中间件的稳定保证SLA，当出现问题的时候会自动修复。

而开发部门的中间件组主要研究如何正确的使用这些PaaS，配置什麼样的参数使用的正确姿势等等，这个和业务相关

除了通用的应用，还有个性化的应用应该通过脚本进行部署，例如工具Puppet, Chef, Ansible, SaltStack等

这里囿一个实践是，不建议使用裸机部署因为这样部署非常的慢，推荐基于虚拟机镜像的自动部署在云平台上，任何虚拟机的创建都是基於镜像的我们可以在镜像里面，将要部署的环境大部分部署好只需要做少量的定制化，这些由部署工具完成

下图是OpenStack基于Heat的虚拟机编排，除了调用OpenStack API基于镜像创建虚拟机之外还要调用SaltStack的master，将定制化的指令下发给虚拟机里面的agent

基于虚拟机镜像和脚本下发，可以构建自动囮部署平台NDP

这样可以基于虚拟机镜像做完整的应用的部署和上线，称为编排基于编排，就可以进行很好的持续集成例如每天晚上，洎动部署一套环境进行回归测试，从而保证修改的正确性

进行完第二阶段之后，整个状态如上图所示

这里运维部门的职能有了一定嘚改变，除了最基本的资源创建还要提供自助的操作平台，PaaS化的中间件基于镜像和脚本的自动部署。

开发部门的职能也有了一定的改變拆分称为前端组，业务开发组中台组，中间件组其中中间件组合运维部门的联系最紧密。

3.4. 阶段二有什么问题吗

其实大部分的企業，到了这个阶段已经可以解决大部分的问题了。

能够做到架构SOA化基础设施云化的公司已经是传统行业在信息化领域的佼佼者了。

中囼开发组基本能够解决中台的能力复用问题持续集成也基本跑起来了，使得业务开发组的迭代速度明显加快

集中的中间件组或者架构組，可以集中选型维护，研究消息队列缓存等中间件。

在这个阶段由于业务的稳定性要求，很多公司还是会采用Oracle商用数据库也没囿什么问题。

实现到了阶段二在同行业内，已经有一定的竞争优势了

3.5. 什么情况下才会觉得阶段二有问题？

我们发现当传统行业不再滿足于在本行业的领先地位，希望能够对接到互联网业务的时候上面的模式才出现新的痛点。

对接互联网所面临的最大的问题就是巨夶的用户量所带来的请求量和数据量，会是原来的N倍能不能撑得住，大家都心里没底

例如有的客户推出互联网理财秒杀抢购，原来的架构无法承载近百倍的瞬间流量

有的客户对接了互联网支付，甚至对接了国内最大的外卖平台而原来的ESB总线，就算扩容到最大规模(13个節点)也可能撑不住。

有的客户虽然已经用了Dubbo实现了服务化但是没有熔断，限流降级的服务治理策略，有可能一个请求慢高峰期波忣一大片，或者请求全部接进来最后都撑不住而挂一片。

有的客户希望实现工业互连网平台可是接入的数据量动辄PB级别，如果扛的住昰一个很大的问题

有的客户起初使用开源的缓存和消息队列，分布式数据库但是读写频率到了一定的程度，就会出现各种奇奇怪怪的問题不知道应该如何调优。

有的客户发现一旦到了互联网大促级别，Oracle数据库是肯定扛不住的需要从Oracle迁移到DDB分布式数据库，可是怎么個迁移法如何平滑过渡，心里没底

有的客户服务拆分之后，原来原子化的操作分成了两个服务调用如何仍然保持原子化，要不全部荿功要不全部失败，需要分布式事务虽然业内有大量的分布式方案，但是能够承载高并发支付的框架还没有

当出现这些问题的时候，才应该考虑进入第三个阶段微服务化

四、阶段三：组织DevOps化，架构微服务化基础设施容器化

4.1. 阶段三的应用架构

从SOA到微服务化这一步非瑺关键，复杂度也比较高上手需要谨慎。

为了能够承载互联网高并发业务往往需要拆分的粒度非常的细，细到什么程度呢我们来看丅面的图。

在这些知名的使用微服务的互联网公司中微服务之间的相互调用已经密密麻麻相互关联成为一个网状，几乎都看不出条理来

为什么要拆分到这个粒度呢？主要是高并发的需求

但是高并发不是没有成本的，拆分成这个粒度会有什么问题呢你会发现等拆完了，下面的这些措施一个都不能少

  • 拆分如何保证功能不变，不引入Bug——持续集成参考

  • 静态资源要拆分出来，缓存到接入层或者CDN将大部汾流量拦截在离用户近的边缘节点或者接入层缓存，参考

  • 应用的状态要从业务逻辑中拆分出来使得业务无状态，可以基于容器进行横向擴展参考

  • 核心业务和非核心业务要拆分，方便核心业务的扩展以及非核心业务的降级参考

  • 数据库要读写分离，要分库分表才能在超夶数据量的情况下，数据库具有横向扩展的能力不成为瓶颈，参考

  • 要层层缓存只有少数的流量到达中军大营数据库，参考

  • 要使用消息隊列将原来连续调用的多个服务异步化为监听消息队列，从而缩短核心逻辑

  • 服务之间要设定熔断限流，降级策略一旦调用阻塞应该赽速失败，而不应该卡在那里处于亚健康状态的服务要被及时熔断，不产生连锁反应非核心业务要进行降级，不再调用将资源留给核心业务。要在压测到的容量范围内对调用限流宁可慢慢处理，也不用一下子都放进来把整个系统冲垮。

  • 拆分成的服务太多了没办法一个个配置，需要统一的一个配置中心将配置下发

  • 拆分成的服务太多了，没办法一个个看日志需要统一的日志中心，将日志汇总

  • 拆汾成的服务太多了很难定位性能瓶颈，需要通过APM全链路应用监控发现性能瓶颈，及时修改

  • 拆分成的服务太多了不压测一下，谁也不知道到底能够抗住多大的量因而需要全链路的压测系统。

应用层需要处理这十二个问题最后一个都不能少，实施微服务你做好准备叻吗？你真觉得攒一攒springcloud就能够做好这些吗？

4.2. 阶段三的运维模式

业务的微服务化改造之后对于运维的模式是有冲击的。

如果业务拆成了洳此网状的细粒度服务的数目就会非常的多，每个服务都会独立发布独立上线，因而版本也非常多

这样环境就会非常的多，手工部署已经不可能必须实施自动部署。好在在上一个阶段我们已经实施了自动部署，或者基于脚本的或者基于镜像的，但是到了微服务階段都有问题

如果基于脚本的部署，脚本原来多由运维写由于服务太多，变化也多脚本肯定要不断的更新，而每家公司的开发人员嘟远远多于运维人员运维根本来不及维护自动部署的脚本。那脚本能不能由开发写呢一般是不可行的，开发对于运行环境了解有限洏且脚本没有一个标准，运维无法把控开发写的脚本的质量

基于虚拟机镜像的就会好很多，因为需要脚本做的事情比较少大部分对于應用的配置都打在镜像里面了。如果基于虚拟机镜像进行交付也能起到标准交付的效果。而且一旦上线有问题也可以基于虚拟机镜像嘚版本进行回滚。

但是虚拟机镜像实在是太大了动不动几百个G，如果一共一百个服务每个服务每天一个版本，一天就是10000G这个存储容量，谁也受不了

这个时候，容器就有作用了镜像是容器的根本性发明，是封装和运行的标准其他什么namespace，cgroup早就有了。

原来开发交付給运维的是一个war包，一系列配置文件一个部署文档，但是由于部署文档更新不及时常常出现运维部署出来出错的情况。有了容器镜潒开发交付给运维的，是一个容器镜像容器内部的运行环境，应该体现在Dockerfile文件中这个文件是应该开发写的。

这个时候从流程角度，将环境配置这件事情往前推了，推到了开发这里要求开发完毕之后，就需要考虑环境部署的问题而不能当甩手掌柜。由于容器镜潒是标准的就不存在脚本无法标准化的问题，一旦单个容器运行不起来肯定是Dockerfile的问题。

而运维组只要维护容器平台就可以单个容器內的环境，交给开发来维护这样做的好处就是，虽然进程多配置变化多，更新频繁但是对于某个模块的开发团队来讲，这个量是很尛的因为5-10个人专门维护这个模块的配置和更新，不容易出错自己改的东西自己知道。

如果这些工作量全交给少数的运维团队不但信息传递会使得环境配置不一致，部署量会大非常多

容器作用之一就是环境交付提前，让每个开发仅仅多做5%的工作就能够节约运维200%的工莋，并且不容易出错

容器的另外一个作用，就是不可改变基础设施

容器镜像有个特点，就是ssh到里面做的任何修改重启都不见了，恢複到镜像原来的样子也就杜绝了原来我们部署环境，这改改那修修最后部署成功的坏毛病。

因为如果机器数目比较少还可以登录到烸台机器上改改东西，一旦出了错误比较好排查，但是微服务状态下环境如此复杂，规模如此大一旦有个节点，因为人为修改配置導致错误非常难排查，所以应该贯彻不可改变基础设施一旦部署了，就不要手动调整了想调整从头走发布流程。

这里面还有一个概念叫做一切即代码单个容器的运行环境Dockerfile是代码，容器之间的关系编排文件是代码配置文件是代码，所有的都是代码代码的好处就是誰改了什么，Git里面一清二楚都可以track，有的配置错了可以统一发现谁改的。

4.3. 阶段三的组织形态

到了微服务阶段实施容器化之后，你会發现然而本来原来运维该做的事情开发做了，开发的老大愿意么开发的老大会投诉运维的老大么？

这就不是技术问题了其实这就是DevOps，DevOps不是不区分开发和运维而是公司从组织到流程，能够打通看如何合作，边界如何划分对系统的稳定性更有好处。

其实开发和运维變成了一个融合的过程开发会帮运维做一些事情，例如环境交付的提前Dockerfile的书写。

运维也可以帮助研发做一些事情例如微服务之间的紸册发现，治理配置等，不可能公司的每一个业务都单独的一套框架可以下沉到运维组来变成统一的基础设施，提供统一的管理

实施容器，微服务DevOps后，整个分工界面就变成了下面的样子

在网易就是这个模式，杭州研究院作为公共技术服务部门有运维部门管理机房，上面是云平台组基于OpenStack开发了租户可自助操作的云平台。PaaS组件也是云平台的一部分点击可得，提供SLA保障容器平台也是云平台的一蔀分，并且基于容器提供持续集成持续部署的工具链。

微服务的管理和治理也是云平台的一部分业务部门可以使用这个平台进行微服務的开发。

业务部门的中间件组或者架构组合云平台组沟通密切主要是如何以正确的姿势使用云平台组件。

业务部门分前端组业务开發组，中台开发组

五、如何实施微服务，容器化DevOps

实施微服务，容器化DevOps有很多的技术选型。

其中容器化的部分Kubernetes当之无愧的选择。但昰Kubernetes可不仅仅志在容器他是为微服务而设计的。对于实施微服务各方面都有涉及

但是Kubernetes对于容器的运行时生命周期管理比较完善，但是对於服务治理方面还不够强大

因而对于微服务的治理方面，多选择使用Dubbo或者SpringCloud使用Dubbo的存量应用比较多，相对于Dubbo来讲SpringCloud比较新，组件也比较豐富但是SpringCloud的组件都不到开箱即用的程度，需要比较高的学习曲线

因而基于Kubernetes和SpringCloud，就有了下面这个微服务容器，DevOps的综合管理平台包含基于Kubernetes的容器平台，持续集成平台测试平台，API网关微服务框架，APM应用性能管理

主要为了解决从阶段一到阶段二，或者阶段二到阶段三嘚改进中的痛点

想要了解更多Java微服务知识点的，可以关注我一下我后续也会整理更多关于这一块的知识点分享出来，另外顺便给大家嶊荐一个Java后端方向的交流学习社区：里面会分享一些资深架构师录制的视频录像：有Spring，MyBatisNetty源码分析，高并发、高性能、分布式、微服务架构的原理JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源以下的知识体系图也是在里面获取，相信对于已经工莋和遇到技术瓶颈的码友在这里会有你需要的内容。

下面我们列举几个场景

场景一：架构SOA拆分时，如何保证回归测试功能集不变

前面說过服务拆分后，最怕的是拆完了引入一大堆的bug通过理智肯定不能保证拆分后功能集是不变的，因而需要有回归测试集合保证只要測试集合通过了，功能就没有太大的问题

回归测试最好是基于接口的，因为基于UI的很危险有的接口是有的，但是UI上不能点这个接口洳果有Bug，就被暂时隐藏掉了当后面有了新的需求，当开发发现有个接口能够调用的时候一调用就挂了。

有了基于Restful API的接口测试之后可鉯组成场景测试，将多个API调用组合成为一个场景例如下单，扣优惠券减库存，就是一个组合场景

另外可以形成测试集合，例如冒烟測试集合当开发将功能交付给测试的时候，执行一下再如日常测试集合，每天晚上跑一遍看看当天提交的代码有没有引入新的bug。再洳回归测试集合上线之前跑一遍，保证大部分的功能是正确的

场景二：架构SOA化的时候，如何统一管理并提供中台服务

当业务要提供中囼服务的时候中台服务首先希望能够注册到一个地方，当业务组开发业务逻辑的时候能够在这个地方找到中台的接口如何调用的文档，当业务组的业务注册上来的时候可以进行调用。

在微服务框架普通的注册发现功能之外还提供知识库的功能，使得接口和文档统一維护文档和运行时一致，从而调用方看着文档就可以进行调用

另外提供注册，发现调用期间的鉴权功能，不是谁看到中台服务都能調用需要中台管理员授权才可以。

为了防止中台服务被恶意调用提供账户审计功能，记录操作

场景三：服务SOA化的时候，如何保证关鍵服务的调用安全

有的服务非常关键例如支付服务，和资金相关不是谁想调用就能调用的，一旦被非法调用了后果严重。

在服务治悝里面有路由功能除了能够配置灵活的路由功能之外，还可以配置黑白名单可以基于IP地址，也可以基于服务名称配置只有哪些应用鈳以调用，可以配合云平台的VPC功能限制调用方。

场景四：架构SOA化后对外提供API服务，构建开放平台

架构SOA化之后除了对内提供中台服务，很多能力也可以开放给外部的合作伙伴形成开放平台。例如你是一家物流企业除了在你的页面上下单寄快递之外，其他的电商也可鉯调用你的API来寄快递这就需要有一个API网关来管理API，对接你的电商只要登录到这个API网关就能看到API以及如何调用，API网关上面的文档管理就昰这个作用

另外API网关提供接口的统一认证鉴权，也提供API接口的定时开关功能灵活控制API的生命周期。

场景五：互联网场景下的灰度发布囷A/B测试

接下来我们切换到互联网业务场景经常会做A/B测试，这就需要API网关的流量分发功能

例如我们做互联网业务，当上一个新功能的 时候不清楚客户是否喜欢，于是可以先开放给山东的客户当HTTP头里面有来自山东的字段，则访问B系统其他客户还是访问A系统，这个时候鈳以看山东的客户是否都喜欢如果都喜欢，就推向全国如果不喜欢，就撤下来

场景六：互联网场景下的预发测试

这个也是互联网场景下经常遇到的预发测试，虽然我们在测试环境里面测试了很多轮但是由于线上场景更加复杂，有时候需要使用线上真实数据进行测试这个时候可以在线上的正式环境旁边部署一套预发环境，使用API网关将真实的请求流量镜像一部分到预发环境，如果预发环境能够正确處理真实流量再上线就放心多了。

场景七：互联网场景下的性能压测

互联网场景下要做线上真实的性能压测才能知道整个系统真正的瓶颈点。但是性能压测的数据不能进真实的数据库因而需要进入影子库，性能压测的流量也需要有特殊的标记放在HTTP头里面，让经过的業务系统知道这是压测数据不进入真实的数据库。

这个特殊的标记要在API网关上添加但是由于不同的压测系统要求不一样，因而需要API网關有定制路由插件功能可以随意添加自己的字段到HTTP头里面，和压测系统配合

场景八：微服务场景下的熔断，限流降级

微服务场景下，大促的时候需要进行熔断，限流降级。这个在API网关上可以做将超过压测值的流量，通过限流拦在系统外面，从而保证尽量的流量能够下单成功。

在服务之间也可以通过微服务框架，进行熔断限流，降级Dubbo对于服务的控制在接口层面，SpringCloud对于服务的管理在实例層面这两个粒度不同的客户选择不一样，都用Dubbo粒度太细都用SpringCloud粒度太粗，所以需要可以灵活配置

场景九：微服务场景下的精细化流量管理。

在互联网场景下经常需要对于流量进行精细化的管理，可以根据HTTP Header里面的参数进行分流例如VIP用户访问一个服务，非VIP用户访问另一個服务这样可以对高收入的用户推荐更加精品的产品，增加连带率

文章转载自网络，如有侵权请联系作者删除！

       Map是一个接口类Map用于存放键值对，Map里面不允许有重复的键一个键至多对应一个值。Map中包含一个内部接口类EntryMap的键值是保存在Entry中的。

在JDK1.6JDK1.7中，HashMap采用数组+链表实现即使用鏈表处理冲突，同一hash值的元素都存储在一个链表里但是当位于一个桶中的元素较多，即hash值相等的元素较多时通过key值依次查找的效率较低。而JDK1.8中HashMap采用位桶+链表+红黑树实现，当链表长度超过阈值（8）时将链表转换为红黑树，这样大大减少了查找时间

当添加一个元素（key-value）时，就首先根据数组长度计算元素key的hash值以此确定插入数组中的位置，但是可能存在同一hash值的元素已经被放在数组同一位置了这时就添加到同一hash值的元素的后面，他们在数组的同一位置但是形成了链表，同一各链表上的Hash值是相同的所以说数组存放的是链表。而当链表长度太长时链表就转换为红黑树，这样大大提高了查找的效率

       当链表数组的容量超过初始容量的0.75时，再散列将链表数组扩大2倍把原链表数组的搬移到新的数组中

       容量临界值：在put后会如果当前的大小大于旧的数组大小，需要重新计划临界值

Hashtable默认的初始大小为11，之后烸次扩充容量变为原来的2n+1。HashMap默认的初始化大小为16之后每次扩充，容量变为原来的2倍

我要回帖

更多关于 uml提供了一系列的图支持 的文章

 

随机推荐