Month July 2018

在项目迭代的过程中，不可避免需要进行项目上线。上线对应着部署或者重新部署，部署对应着修改，修改则意味着风险。 目前有很多用于部署的技术，有的简单，有的复杂，有的得停机，有的不需要停机即可完成部署。本文将对目前常用的部署方案做一个简单的总结。 蓝绿发布（Blue/Green Deployment） 1. 定义 蓝绿部署是不停老版本，部署新版本然后进行测试。确认OK后将流量切到新版本，然后老版本同时也升级到新版本。 2. 特点 蓝绿部署无需停机，并且风险较小。 3. 部署过程 部署版本 1 的应用（初始的状态） 所有外部请求的流量都打到这个版本上。 部署版本 2 的应用 版本 2 的代码与版本 1 不同(新功能、Bug修复等)。 将流量从版本 1 切换到版本 2。 如版本 2 测试正常，就删除版本 1 正在使用的资源（例如实例），从此正式用版本 2。 4. 小结 从过程不难发现，在部署的过程中，我们的应用始终在线。并且新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响，这样风险很小。并且只要老版本的资源不被删除，理论上，我们可以在任何时间回滚到老版本。 5. 蓝绿发布的注意事项 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题。…

讲师介绍 任发科，网名常新居士，曾任职唯品会、会唐网、亚马逊、ThoughtWorks，有十余年软件开发、架构和管理经验。曾参与多个电商相关系统的研发工作，近年主要关注DevOps工具链的设计与实现，以及高效研发团队的组建与管理。 今天我主要是从两个方面去探讨DevOps，由于大部分的同学可能更多的是看到了运维这个层面，所以我更多侧重的是Dev这个层面，也就是从Dev到运维，因为正好是整个全流程走到这里，我们看到了一些实践，也看到了将来的一些机会和趋势，所以今天会谈一谈我们公司近两年做的过程，也就是我们怎么做DevOps。 一、从业务、系统发展看问题 从业务和系统的发展，我们来看当时面临的问题和解决的措施，有一些总结性和思考性的东西。就像程永新老师在企业级运维三板斧所说的，未来不是DevOps，关注方向的可能是AIOps这个层面，也就是说DevOps更要关注的是ADPaas平台，而在运维侧则更多的是AIOps，就像谷歌的系统是自治的，不需要人为介入，所以运维侧是要受到很大挑战的。 这是我当时加入公司时的一个基础组织架构，跟所有互联网公司，或者一些创业已经过了风险期的公司大致相似，这是标准化的建制，就是说业务和研发、测试、运维都有，是这样的一个结构。 敏捷与持续集成 第一个过程，当我加入到这个团队里面时，整个研发体系加上在一起大概40人左右。刚进去时我们做敏捷和持续集成，跟所有的创业团队一样，内部没有规范，做事图快，质量较低。大家在创业公司或者是一些中型公司呆过的话就会知道，基本上没有走到标准化流程阶段，基本上都会存在相同的问题，就是业务和研发对接的管理非常混乱，没有相对规范的流程。 开发做出来的东西提交测试时没有太多的责任心（在心理定位上将测试人员当作编码质量的防护网），里面Bug非常多。然后上线测试，我们当时让测试做构建，把这个包构建出来，最后交给运维，由运维负责上线。整个过程很乱，比如拷到某一个发版机器上，拷上去以后用文件夹打个标签交给运维，运维再往线上扔，扔到线上以后就要人肉一段时间，看一看没什么问题才回家睡觉。 存在问题：你可以看到基本上的问题就是，需求侧这面项目管理非常乱，研发的交付质量很低，会有很多返工的事。项目上线的周期长，问题非常多。 我们首先做的是基于持续集成的改善。从过程管理这个层面，我们把Scrum引入进来，对Scrum做了一定的调整。实际上最近在敏捷圈子里吵得非常厉害，各种方法论大家都不服，都认为自己代表了“天意”。但从企业的角度，尤其是我们解决问题的角度，用哪个都无所谓，能解决问题才是根本。所以我们根据企业当前人员情况对Scrum进行了裁剪，不是什么都要，明确哪些问题需要用Scrum去做。把Scrum流程引入之后，再用JIRA做需求管理、排期这些事情，然后内部用GitLab去做整个代码的管理，搭一个服务器，把UT做起来，很快能够得到好的反馈。这个是非常成熟的套路，如果用强制的方法做的话见效很快，基本上1-2个月就能梳理出来。 在我们做完了后会发现，这个过程不是那么顺，不是上来以后奇迹一般的就做好了，中间肯定有很多很多需要去沟通、协调的一些过程。你可以看到业务跟研发的对接相对来说变得好了，不一定非常流畅，但可控了。但研发到测试这边，你会发现它的墙变灰了，不是那么实了，因为当你有UT搭建起来后，其实提交的质量、责任已经放在研发这一侧了，这时候测试拿到的东西相对就好很多，它就不会来来回回地在底层的一些简单问题上掰扯。但这时运维这一侧还没有受到太大的影响。 存在问题：这时我们发现还是有一些问题，就是研发到测试的交付物不同源，一致性存在问题（我们后面会讲一致性的问题）；测试手工验证周期还很长，因为它没有做测试的自动化，即功能测试和性能测试都没有做自动化；项目上线时间长，因为没有触动到运维侧。所以这时候我们要做的就是持续交付的第一个版本，我们把它叫做持续交付的1.0。 持续交付1.0 持续交付的1.0做了什么事？就是我们现在大部分在40人以下的小团队要做的——一个交付流水线，其实多数团队都是这样做，就是加一个pipeline的插件，部署的脚本写在Jenkins里头，然后把它跟源代码放在一起，这就是我们现大部分持续交付的事情——加一个pipeline插件。我没有截那个图，这里画了一个大概的形式。   你可以看到之前的CI我们还需要做，但Jenkins有了一定的构建能力，并且通过pipeline插件我们可以做多环境的部署，只要构建出来以后一步一步往上推（Promotion），但在UAT到生产这一步需要人工做最后的审批，并不全自动化。 这里涉及到两个概念的差别呢？就是什么是持续交付，什么是持续部署，现在行业里头谈持续交付多一些，谈持续部署少一些。持续集成是关注在研发侧，不涉及到后面的自动化验证和部署的过程，但持续交付关注到了构建后的部署和验证，但它有一部分的手工验证过程，它可能在全线是贯通的，但最后的一步和中间验证都是手工的。而持续部署强调的是全自动，中间没有任何人为的干预，只要你一提交代码马上就开始通过部署流水线向生产流动。我们现在说的是持续交付，所以这在生产过程实际上还需要手工去审核的。但这个过程实际是有问题的，在系统很小的时候可以这么做，但团队变大的时候就有问题。 存在问题：什么问题？持续交付说只构建一次，然后在这个构建的产物上进行验证和部署，这就需要引入制品库。但是我们遇到了一些团队，你会发现实际上在代码的生成和验证的过程中，它都是从版本库里头直接拉代码回来，不断地拉代码，拉了以后再动态地打包，这样的话会有一些问题。 所以我们希望把制品库引进来，就是拿的东西是第一次就构建成功的东西，然后在这个上面不断地附加原数据。什么是原数据？就是经过或没经过单测，单测的百分比是多少，然后谁去验证它，这都是跟这个制品有关的一些行为和流程数据，它必须要记录下来，因为后期的活动可以基于这些数据去做选择。 制品库：Nexus->Artifactor->自研 我们整个制品库过程选择经过了3个阶段，最早的整个项目是用Java来做的，很自然的，我们就用Nexus做私库，去做制品的构建产物管理。因为它很容易解决依赖的问题，而依赖是很麻烦的事情。因为Nexus支持产品版本，不支持构建版本的追踪，同时它没有原数据管理的能力。 所以第二步我们跟JFrog对接，希望用它的Artifactory，这是用得比较成熟且用得比较多的，目前谷歌、腾讯、阿里也在用。但问题是公司体量不大，而专业版的Artifactory比较贵，我们负担这样的花费有点不划算，跟大家一样我们想用开源版本的，但社区版的Artifactory不支持多语言，而且它构建版本的支持要专业版，所以没办法，我们调研以后自己做，拿什么做？ 很简单，你可以搭一个类似S3的文件服务，把它放在文件服务上去。第二种方式我们用数据库去做，有些数据库实际上是可以去存二进制的大文件的，而且它可以很方便地做Key-Value的元数据管理，但自己研发制品库的问题在于并发、高可用和快速下发。在规模较小时，这些还不是问题。 它的好处是什么？加了制品库以后，我们能保证把构建版本和元数据打上去，在这样的话我们保证部署的都是同源的，而且一步一步可以在它的部署逻辑里头根据元数据经过选择，就是它没有经过前面的阶段或者到达一定的百分比我是不允许后面的阶段看到这个构建产物。 现在你可以看到我们的整个结构，就是说开发到测试的阶段实际上这个墙就没有了。这里说一下我们自己的业务，我们的业务基本上是支持公司内部的电商和公司内部的其它互联网产品。这时你可以看到测试到运维这边的墙实际上可以把它拿走，但运维这时还有一些问题就是他的事比较杂，为什么杂？因为应用的运维。我们可以把运维看成两部分，一部分是传统的运维或者说是基础设施和工具化的运维，另一方面是跟应用相关的运维，应用的运维我们也是放在运维团队的，这个安排实际上是不合适的。所以说运维的事就比较杂，不能专心地干自己特别擅长的事。 存在问题：这时我们发现运维人员需要维护大量的环境，包括应用的部署；第二，构建环境与生产环境的一致性是有问题的。为什么？比如说构建环境放在Jenkins里，如果去用它做构建的话，它的环境是定好的，例如JDK1.8，那我所有的东西只能在JDK1.8上去构建，但如果我要装JDK1.7呢？那就另搭一套环境去做它，比较麻烦。部署逻辑和Jenkins是紧耦合的，因为这些东西我们是在Jenkins里用脚本编程，而且它没有快速回滚机制。有些时候实际上是要快速回滚的，不能重新拉代码版本再部署一次。最后，依然需要大量的人员去做半自动化的测试。 持续交付2.0 用配置管理工具（Ansible）管理环境 这时我们就想做2.0的持续交付，最早我们是用Ansible做环境的管理，在持续交付2.0之前和持续交付1.0之间发生了一件事情：我们把大量的机器从阿里云上搬到自己的私有云上，在一年不到的时间我们搭建了OpenStack的私有云，一年里给公司节省的成本大概是在几百万左右，除了少量对外的一些服务必须要放在阿里云上，我们大部分核心计算都是放在内部的私有云上，这是我们运维团队做的非常大的贡献。我们到了2.0的阶段，实际上大部分的机器都是虚机。这时候加上Ansible以后，可以拿Jenkins去管这些集群的环境，这样的大家相对都用得比较多，就不过多解释。   存在问题：这时整个场景里可以看到，有一部分是应用的业务部署，有一部分是环境的部署、管理，但当真正去实践时发现有些问题。第一个是需要构建环境和生产环境的版本是一致的，即应用包依赖的版本一致，包括操作系统也是一致的。第二个就是需要构建工具的一致性，就是说，构建时比如说是1.9构建的，回滚时也必须要回滚到1.9进行重建，必须要把这个信息记录下来。 如果大家读过谷歌的文章，讲他们bazel整个构建系统的话，你会发现它的一个巨大的目标就是要做到一致性，最重要的经验就是把所有的构建的依赖和构建工具放到版本库里进行统一管理。现在用Ansible这个方式去管环境，用Jenkins去构建，不会有什么问题。但当发现应用包丢了，想重新构建一次时用Jenkins进行环境构建时相对比较麻烦，很难自动化再一键构建出来一个。怎么办？接下来我们在3.0里头会讲我们是怎么做的。 测试人员和测试工作的定位 这时，我们开始做测试的自动化，就是功能测试，还包括测试平台。这样的话，测试人员和测试工作的定位我们需要重新反思一下。 因为我们做的工作跟传统的业务相对还不是那么结合紧密，基本上就做数据支持的，大数据、用户行为分析，包括我们自己做APM和其它工具，这些工作大部分是技术性的工作，在这里面人肉QA的工作没有那么大量。所以这时我们希望把QA的工作极大地压缩，甚至从我们的业务流程里头去除掉，事实上我们也整个把QA给干掉了。 这里面逻辑是什么？就是留活不留人，比如说一些用户的可用性这样的测试我们也是需要人的，但这种工具类型的东西我们不需要人做测试，我们用机器做就可以了。所以这时你会发现整个流程就留下Dev和Ops了，把活留下了。 Docker与不可变部署 我们开始引入Docker，希望做基于Docker的不可变部署。Docker有个好处就是在生成一个镜像时，可以通过描述来声明其包含的内容，并将整个应用和它的环境打包成一个镜像，这样的话，测试验证了这个镜像以后，它随后进行的所有部署都不需要变更，所需要变更的东西只是配置，你可以在启动这个镜像时给它加一些不同的配置，但它内部的实现一般是不变的，回滚和前滚都是非常容易的。  …

CMDB，几乎是每个运维人都绕不过去的字眼，但又是很多运维人的痛，因为CMDB很少有成功的，因此我也把它称之为运维人的耻辱。 那么到底错在哪儿了？该如何去重构它？ 今天我想从我的角度来和大家探讨一下业务失败的原因，基于失败再去看重构的逻辑，也许会成功。 从失败中寻找成功的逻辑，往往是最有效的，那我们就来逐一看看： 1、组织的设计问题 我必须把核心原因归结成这一条，很多公司把CMDB的建设责任放到基础设施建设部门，由他们主导承建。最后他们梳理出来的核心逻辑是面向基础设施资源的管理，你在他们的CMDB中都能看到如下菜单，AIX主机是哪些，中间件有哪些，大小机有哪些，Oracle有哪些等等，这些都是和公司的IT运维部门组织结构是一一对应的。组织的隔离是CMDB失败的核心原因！ 这个里面能看到一些CMDB管理能力错位，拿两个例子来说一下： A、中间件。 一直搞不明白为什么中间件要作为一个单独的对象来管理，“皮之不存，毛将附焉”。没有主机，没有业务这个皮，哪来的中间件。把他单独拿出来管理，纯粹就是为了满足组织的一个管理视角。从来没人想过，这是主机上的一个资源对象，应该是一个附属资源，其实对他的信息管理和机器上的CPU、网卡一样。 B、进程对象，比如说数据库 这个是另外一种管理错位，是专业的管理平台应该去履行的管理职责，结果放到CMDB平台中了，然后CMDB管理了大量的动态属性，比如主备关系，服务状态等等，太复杂了。最简单的看，从主机的角度来说，他就是服务器上运行的一个进程而已。管它死活干嘛，那是监控系统做的事情，管它状态干嘛，那是**组件管理平台干的事情。 2、Excel是最好的管理工具 当组织隔离，不能够形成有效的信息互动之后，Excel更是之上的一次痛击。可能从外围思考，为什么不去解决现实层面上的问题，而选择了Excel？Excel很简单，特别是IT服务对象不多的情况下，几百个还是能够应对的。我就拿个Excel记录一下，然后svn上小组内共享一下就好了，反正我的信息也就我使用，别的小组也不用（组织的隔离性）。对它的思考，还是要回归的第一点，使用Excel是结果，但我比较反对Excel做法。每次建设cmdb的第一个目标，就说要消灭掉Excel。 3、去简就繁 这个是从产品本身说的，我看了几个开源的产品，oneCMDB和iTOP（建议大家都体验一下），界面都是复杂的要命，还有商业的产品（具体哪家不说了）。 首先必须要解决产品易用性的问题，易用性不够，你怎么让能用户有使用的欲望呢，以下是来自于UC做的CMDB系统产品截图： 其次还有一种信息复杂带来的易用性下降的问题。我看很多产品都管理了一些无光的信息，信息的管理归类也是有考究的，没归类好，用户又被淹没了。 拿主机来说，维护其核心需要的信息就好了，比如说固资编号、所在机房的位置信息、厂家信息、上架信息、进程端口信息、维护信息等等。这些信息都是有运维场景的，比如说位置信息+固资信息在驻场需要操作的时候有用；上架信息对于过保维修有用；进程端口对于监控有用；维护信息在运维申请资源的时候有空，谁也不想用经常故障的机器吧；主机状态位是用来做资源池管理+监控使用的。 很多配置的变更都是因为场景变更引起的，比如说机器搬迁导致机器的物理位置信息发生变化，那就搞一个机器搬迁流程吧；机器上的业务下线了，但进程信息没有清理，那是业务下线流程的问题…. 5、和应用没有关联，更别提场景关联了，就更别提主动场景了 很有意思的现象：客户的监控系统中监控的应用主机信息都是该系统中自行维护的，从来没有考虑从CMDB获取。也就是因为CMDB是另外一家产品，为啥呢？如果资源和应用关联起来了，并且由他来驱动监控，这个维护的动力是不是不一样呢？ 哪怕是你的CMDB系统能够支撑一下我上图中的工具盒子的能力，CMDB维护的动力不至于那么糟糕，它的数据也不至于那么糟糕。之前和人探讨过是先有操作系统安装把信息写到CMDB还是先有CMDB的信息然后再有操作系统安装的动作？当然是后者了。事实上在服务器采购分配上机架的时候，其实所有的信息都分配完毕，此时入库，就可以启动远程自动安装了。 其实还有很多原因，比如说物理世界和逻辑世界是独立的，物理世界发生的过程没法直接映射到CMDB系统中（有些配置信息需要进入固件中）；CMDB的对象Owner没有或者过多（Owner很累）；过分强调CMDB的基线作用，引入对比（动态变化的环境基线的作用应该下降）；夸大CMDB自动发现的作用等等。 说了很多的失败的原因，接下来就需要讨论一下解决方案了，既然讲重构，老王的重构逻辑是什么样的？ 第一、重构你的CMDB思维 建议大家不要把CMDB称之为CMDB了，那叫什么，就叫资源管理吧。为什么你要从改名字开始？老是叫CMDB，大家都回到过去的思维上了，道不清说不明的，或者各执己见。 一切皆资源！！！一切皆资源！！！一切皆资源！！！ 从基础设施的对象来说，计算资源、存储资源、网络资源、IP资源、机房资源等等，在CMDB的管理上，把你的资源对象罗列出来，关系梳理清楚，就可以构建其能力管理了。 从上层的业务资源来说，建立以应用为中心的资源管理逻辑，把 一切都看成应用的资源来看待。比如说Host，应用包、权限、RDS服务、cache资源等等。 老王现在做的产品把CMDB一分为二，底层的基础资源层CMDB可以不要。在不要的情况下，我可以构建上层应用的信息管理平台（业务CMDB），它可以独自构造场景来驱动上层运维。以下是优维EasyOps产品截图： 随着应用相关的一些支撑资源云化之后，面向应用的资源管理能力要不断加强。我经常和大家举的一个例子，是IaaS公有云平台中的Mysql实力已经是一个资源对象：实例域名。如何实现的对他们的管理，你只能把他当成一个附加资源来进行管理，不是么？ 此时有意义的事情来了，你管理的业务资源信息越丰富，你的自动化驱动能力就越强。别再绕回去了，说让自动化来帮我维护这些信息。相辅相成、互相促进的事情，就不该设定前提，而是关注那个上升式的过程。 第二、重构你的CMDB方法 标准的CMDB方法是教你如何迭代进行一个CMDB项目，这个没有错误，但我会指出有些方法是你必须要坚持的，否则你的系统会面临失败。 A、放弃你的excel excel是一个CMDB失败的佐证，必须去除它的存在，很多时候大家说是系统不好用引起的，但我的观察是大家的习惯引起的。改变习惯很难，有些时候需要借助组织自上而下的力量。没有集中的平台依赖，平台是没有人去驱动优化的。 B、构建CMDB的微内核和弹性CMDB模型库 CMDB的微内核很小，其实你只需要应用、集群和主机三个概念就可以构建起一个CMDB，基于这三个概念，可以不断去向周边扩散。应用可以往用户侧的概念不断靠拢，形成业务的概念。主机可以在其关联或者拥有的资源上不断去扩展，比如说主机所在的机柜、机柜所在的机房、机器关联的交换机等等。 这个微内核，我想是可以适用一切场景了，但还不够呢，如何保证这个模型对所有企业做到落地可适配的？这个时候就是弹性模型的作用了。弹性模型由对象的弹性和对象CI及其关联的弹性定义实现的。简单的理解，你就是实现了一个业务数据库的可视化定义，下图是对象的弹性定义：…

1. 背景 某TIC网站提供O2O服务，客户在线下单并点击在线支付，会跳转到支付宝收银台进行付款，付款成功完成后，支付宝会调用TIC网站接口，通知TIC网站付款成功。 2. 问题现象 测试中，发现支付成功完成后，TIC网站并没有收到支付宝的回调通知。经过排查后发现，该TIC网站的ssl证书链并不完整。 在线验证工具： 另一个工具： 工具三： 3. 解决思路分析 由以上监测工具可知，ssl证书具体的问题为：Missing Intermediate Certificates GoDaddy 对 Intermediate Certificates的解释： 4. 证书链原理 浏览器的安装包里，保存着一些它信任的根证书（公钥）。 证书发行商们为了安全，通常会将这些根证书对应的私钥保存在绝对断网的金库里。在金库里用这些根私钥，签发一些“中级”证书，这些中级证书的私钥拥有签发再下一级证书的权限。这些中级私钥被安装到在线服务器上，通过签发网站证书来赚钱。一旦这些服务器被黑，发行商就可以利用金库里物理隔离的根证书私钥，可以签发吊销令，消灭这些中级证书的信任，而不必让各家浏览器彻底不信任这家发行商的根证书。再签一条新的中级发行证书，又是一条能赚钱的好汉。 问题来了。 浏览器只认根证书。中级证书的认证，你（网站）得自己开证明。 一个正确配置的HTTPS网站应该在证书中包含完整的证书链。 比如以 openssl s_client -connect www.wosign.com:443 命令来查看wosign自己的网站配置。 其余内容可以无视，只看Certificate chain这一段： — Certificate chain 0 Organization i:/C=CN/O=WoSign CA…

今天开启了nginx的error_log，发现了三个配置问题： 问题一： 2011/07/18 17:04:37 [warn] 2422#0: *171505004 an upstream response is buffered to a temporary file /opt/app/nginx/fastcgi_temp/9/80/0001539809 while reading upstream, client: 1.202.221.2, server: www.yongfu.com, request: “GET /recipe/all?cate=643&PHPSESSID=8c1135b85f1b5f90f55caab5ea7e1526 HTTP/1.0”, upstream: “fastcgi://127.0.0.1:9000”, host: “www.yongfu.com” 问题分析：nginx的fastcgi设置的fastcgi_buffers太小，导致将缓存写入磁盘。 问题解决：修改nginx的配置，将fastcgi_buffers调大，参考了该文： fastcgi_buffers 32 8k; ok，问题解决，但又出现新的问题： 问题二： 2011/07/18…

介绍 SkyWalking 创建与2015年，提供分布式追踪功能。从5.x开始，项目进化为一个完成功能的Application Performance Management系统。 他被用于追踪、监控和诊断分布式系统，特别是使用微服务架构，云原生或容积技术。提供以下主要功能： 分布式追踪和上下文传输 应用、实例、服务性能指标分析 根源分析 应用拓扑分析 应用和服务依赖分析 慢服务检测 性能优化 主要特性 多语言探针或类库 Java自动探针，追踪和监控程序时，不需要修改源码。 社区提供的其他多语言探针 .NET Core Node.js 多种后端存储： ElasticSearch， H2 支持OpenTracing Java自动探针支持和OpenTracing API协同工作 轻量级、完善功能的后端聚合和分析 现代化Web UI 日志集成 应用、实例和服务的告警 架构 在线体验 北京服务器. 前往 香港服务器. 前往 安装 安装es 新版本的skywalking使用ES作为存储，所以先安装es，注意6.X版本不行，安装5.6.8： wget tar…

摘要： 数字化生态，以创新客户体验为核心，所有我们身边能感知到的变化都来自于渐近的创新。这些创新需要试错，需要不断的升级，并且创新往往与我们熟知的功能分离开来分别呈现。微服务对于传统单体架构的优势之一就在于，服务的拆分带来了更新、部署、管理的隔离性，让一些单独的服务可以进行创新和实验。 数字化生态，以创新客户体验为核心，所有我们身边能感知到的变化都来自于渐近的创新。这些创新需要试错，需要不断的升级，并且创新往往与我们熟知的功能分离开来分别呈现。微服务对于传统单体架构的优势之一就在于，服务的拆分带来了更新、部署、管理的隔离性，让一些单独的服务可以进行创新和实验。从而支撑了用户体验的不断升级，为实现企业数字化转型的过程，提供了技术架构层面的支撑。 我们现在已经可以很方便的通过一些电子商城购买运营的合约机，而无需到营业厅亲自办理相关的业务，这就是API Gateway的一种底层支撑。由于运营商通过API Gateway向第三方的商务平台开放了与套餐、机型销售等服务，并通过流控、鉴权等机制保障相关的安全性，才使得这样方便流畅的购物体验得以实现。 对于MOBA手游类玩家来说，“王者荣耀”是一款颇受欢迎的游戏。在一些场景下，我们会感知到“不停机更新”“体验服更新”这两种不同方式的更新形态，在底层，就是API Gateway或者类似技术的实现，支撑灰度发布，让一些新特性发布给体验服（比如传说中露娜的二技能变化，仅在体验服更新，实际上并未如传说中一样在S11赛季更新到正式服），或者特定的游戏用户，待功能完善或者稳定运行，再向正式服或者全部用户发布，让游戏玩家的体验可以更加流畅，甚至是无感知的升级。 这些只是微服务架构或者API Gateway所支撑的万千业务场景中的沧海一粟。 但微服务本身也会带来诸多问题，粒度小难以管理就是其中之一，本文即从这个角度，阐述了API Gateway所起到的作用和一些关键的技术要素。 以微服务为核心的分布式框架贯穿了普元数字化企业技术平台的APaaS层面，本文所介绍的API Gateway是其中的关键组成部分（图中标黄的部分）。 引言： 随着微服务的大红大紫，大家纷纷使用微服务架构来实现新系统或进行老系统的改造。当然，微服务带给我们太多的好处，同时也带给我们许多的问题需要解决。采用微服务后，所有的服务都变成了一个个细小的API，那么这些服务API该怎么正确的管理？API认证授权如何实现？如何实现服务的负载均衡，熔断，灰度发布，限流流控？如何合理的治理这些API服务尤其重要。在微服务架构中，API Gateway作为整体架构的重要组件，它抽象了微服务中都需要的公共功能，同时提供了客户端负载均衡，服务自动熔断，灰度发布，统一认证，限流流控，日志统计等丰富的功能，帮助我们解决很多API管理难题。 目录： 一、什么是API Gateway 二、为什么需要API Gateway 三、API Gateway中一些重要的功能 四、API Gateway vs 反向代理 五、API Gateway对API的认证及鉴权 六、采用OAuth2方式认证的两种部署方式 七、总结 一、什么是API Gateway （图片来自网络） 这张图，非常形象的解释了API Gateway和微服务的关系。做为听众，我们只想听到美妙动人的音乐旋律，完全不会在乎音乐是怎么演奏的。而指挥家则根据曲谱负责指挥好每一个演奏者，使每一个演奏者之间配合默契，共同完成这场音乐演出。在微服务的世界里，API Gateway就如同一位指挥家，“指挥”着不同的“演奏人”(微服务)。 我们知道在微服务架构中，大型服务都被拆分成了独立的微服务，每个微服务通常会以RESTFUL API的形式对外提供服务。但是在UI方面，我们可能需要在一个页面上显示来自不同微服务的数据，此时就会需要一个统一的入口来进行API的调用。上图中我们可以看到，API Gateway就在此场景下充当了多个服务的大门，系统的统一入口，从面向对象设计的角度看，它与外观模式类似，API…

一、首先是下载Java JDK 到目前为止的最新版本为(jdk1.8.0_60)，有两种方式进行下载： 1.使用shell来进行下载，可使用如下命令直接进行下载： wget –no-check-certificate –no-cookies –header “Cookie: oraclelicense=accept-securebackup-cookie”  2.直接登录��择相应的Java版本进行下载 二、解压缩下载的压缩文件 使用如下命令进行压缩： tar zcvf  jdk-8u60-linux-x64.tar.gz，会出现如下文件夹（jdk1.8.0_60）： 三、配置Java环境 使用shell命令行进行配置，使用如下命令可以进行java环境配置 cd ~　　　　//进行用户目录 sudo vi .�� （关于vi的使用可以参见如下学习教程��配置中只需要进行如下几个命令，o(光标移到下一行)，i(进行输入)，esc(退出编辑模式)，shift  + zz (保存设置并退出)） 打开.bashrc文件后，在该文件的末尾添加如下变量 export JAVA_HOME=”/home/leesf/program/java/jdk1.8.0_60″　　　　//此时本用户名为leesf,用户根据用户自己的用户名，进行修改（如是zhangsan,则　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　   export PATH=”$PATH:$JAVA_HOME/bin” export JRE_HOME=”$JAVA_HOME/jre” export CLASSPATH=”.:JAVA_HOME/lib:$JAVA_HOME/lib” 截图如下： 设置完成后，按shift + zz退出编辑，再输入source ./.bashrc进行更新。 配置完成后查看java环境是否已经配置完成，输入如下命令： java -version即可查看，配置成功了应该如下：…

一、前言 在前面的解决乱码的一文中，只找到了解决办法，但是没有为什么，说白了，就是对编码还是不是太熟悉，编码问题是一个很简单的问题，计算机从业人员应该也必须弄清楚，基于编码的应用有Base64加密算法，然后，这个问题一直放着，想找个机会解决。于是乎，终于逮到机会，开始下手。 二、编码 关于ASCII、Unicode编码、UTF-8编码等问题，可以参见笔者另外一篇博客【字符编码】彻底理解字符编码。 三、Base64算法 Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，关于Base64的介绍可以参见这两篇文章base64，BASE64算法，下面我们通过Java来实现Base64编码算法并且详细解析其中遇到的问题。 Base64编码算法的流程图如下： 说明：Base64规则表由Base64的规定的规则得到，而逆向Base64规则表则通过少量的计算获得，如某Base64的编码字符串为QQ==，对于字符Q而言，Q的ASCII编码为81，Base64规则中，16对应Q，则将逆向Base64表中下标为81的项置为16。其余不在Base64中的元素在逆向表中值为-1，逆向表的计算流程如下： 四、Base64算法的Java实现 Java中的字符都是以Unicode格式进行存储的，如何查看任一个字符在Java中的表示？使用如下代码即可 import java.io.UnsupportedEncodingException; public class Test { public static void main(String[] args) throws UnsupportedEncodingException { String str = “张”; byte[] bytes = str.getBytes(“utf-8”); for (int i = 0; i < bytes.length;…