php function函数的用法（AWS 云计算环境中的微服务架构）PHP函数 / PHP函数在DevOps流程中的角色...

邱洋总结微服务不是石头缝里面蹦出来的，是基于类似SOA、Blackboard、C/S等应用架构基础上，并融合敏捷开发、DevOps等理念的基础上发展而来微服务相比传统应用优点明显（快速部署、去中心、良好的隔离性等），缺点也不少（更复杂、通信损耗、测试成本高）

微服务不仅仅是一种新型的应用设计方法，使用这种架构的企业的组织架构可能也需要作出适当调整AWS针对微服务设计了ECS(基于EC2的容器服务)、Lambda（基于事件驱动的计算平台，开发人员只要编写javascript或java逻辑就行，lambda负责执行工作，类似HPC的执行模式）

原来AWS的ElasticBeanstalk就已经在底层使用Docker来进行应用环境交付了，只是限定更加多（需要指定语言平台，如java、php、.net等）而ECS则没有这么多要求EB好比GAE而ECS更像EC2。

关于微服务（Microservices)2.1 为什么需要微服务原有3层的应用架构（表现层、逻辑层、持久层–数据层）每个大层面的应用程序都有大量逻辑进行包裹，因此开发、维护和管理起来非常费时费力，且由于开发周期长都存需求落后风险

而微服务的开发模式不同，它的思路是将每个大层面的应用，再次分解，将每个相对独立的小模块都变成一个独立的程序（所谓一个小的服务）每个服务都的独立运行在进程中，独立部署，每个服务之间通过轻量级的方式进行交互，例如http api。

不同的服务可以不同的开发语言，数据存储保存机制这样就可以敏捷的开发和维护应用，时间周期也变得非常短

2.2 为什么微服务会出现？技术发展带来的复杂性，开发时间上的开销，大环境所承担的各种风险，相关理念与开发思想（如敏捷开发）共同推波助澜的结果微服务是以历史上存在的、流行过的编程架构为基石的，而非石头缝里蹦出来的，这些架构包括：

Blackboard架构：背后的理念是，一系列独立的程序携手合作，致力于处理同一个数据结构Client/Server架构：客户机和服务器结构它是软件系统体系结构，通过它可以充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现。

Component Based架构：在组件对象模型的支持下，通过复用已有的构件，软件开发者可以“即插即用”地快速构造应用软件Peer-To-Peer架构：不同于主从式架构，网络上的每个使用端或程式的实体都拥有相同的等级，同时扮演用户端与服务器的角色。

Service Oriented 架构：大名鼎鼎的SOA架构，是构造分布式计算的应用程序的方法它将应用程序功能作为服务发送给最终用户或者其他服务另一方面，微服务不仅传承了各种应用架构，而且受到众多软件设计领域的思想的影响，比如：。

领域设计驱动（分析模型化的复杂业务）敏捷方法（提升效率减少浪费）持续交付（更快、更可靠、更频繁的应用部署）虚拟化和IaaS（简化基础架构环境）DevOps（让团队更加小巧）2.3 微服务的特征小：每个服务只做一件事情，并且目标是把事情做好、做极致 。

例如业内有些人的甚至用代码尺寸衡量（例如100行、1000行以内的代码）运行在独立的进程中：不同的服务可以运行在不同的主机之上轻量级通信机制：指的是服务和服务之间，通过轻量级的通信机制，进行沟通（轻，是指通信跟语言和平台无关，例如json、xml等）。

而相反的传统重量级通信机制比如（.net remoting或java rmi）松耦合：不需要改变依赖，只需要改变当前服务本身，并独立部署这意味着该服务的部署和运行，和其他服务之间呈现独立的姿态2.4 微服务的优缺点。

优点：良好的隔离性和可用性，场景：某一个服务的故障，并不会影响到其他无关的服务独立交付速度大大提高，场景：现在强调的持续部署、持续开发对交付速度有很高要求，Microservices可以做到而传统的Monolithic一体化应用部署的交付速度提升非常难，对基础架构、对环境、对应用测试的要求高，很难做到。

去中心化的管理，场景：在管理部署传统应用的时候，都有部署一个打包的应用、有一个关键核心应用，就是是一个中心点而Microservices并没有一个中心，因此可以在运维过程中各团队可以针对部件独立部署，DevOps ，降低风险。

缺点：复杂性，Microservice本质上是分布式，而分布式系统本身存在复杂性，需要开发、测试和运维人员等都需要有处理复杂系统的经验服务的操作开销，Microservice因为有很多服务，相比传统架构有很多服务间通讯的开销，因此在效率上不如传统Monolithic。

并且一般都需要遵循DevOps进行管理模式和流程服务接口不匹配后的问题？虽然Microservice使用标准化接口，但由于服务多而且不同服务的接口存在版本，一旦某服务版本失去了控制，或与其他服务通讯的匹配，则会出现不可控的风险

测试，相比传统应用架构，每次发布版本，都需要整个生态系统测试，因此整体测试时间更长更复杂扇形增加的需求数，主要原因是随着服务的增加，数据流量就会大幅度增加微服务设计3.1 康威定律 Conway’s Law(应用架构对组织架构有要求)

任何设计系统的组织……必然会产生以下设计结果，即其结构就是该组织沟通结构的写照—-翻译—– 有什么样的组织架构，就有什么样的软件产品用传统的组织架构去开发Microservice就会出问题3.2 传统应用组织架构（SILOs）。

传企业应用架构如下： 产品团队 用户交互体验 开发团队 测试团队 数据库团队 系统管理 网络管理 存储管理等传统应用架构采用一体化（Monolithic）应用使用这种模式是比较好的，但是Microservice使用这种架构会有问题（因为每个服务都可能存在需要搭配这样的班子的情况），而这种组织架构下，信息在团队间沟通成本是非常大的

3.3 针对Microservice，组织需要作出调整（DevOps）

调整方法：针对Microservice的各个service建立一个个敏捷小型的高效团队，每个小型团队针对每个服务（贯穿于整个应用的各个服务模块）负责，独立进行相应的开发与管理工作

Microservice的架构跟DevOps有密切的关联，Microservice是DevOps思想逐步演化的结果，而DevOps也是实现Microservice最好的工具3.4 如何设计 smaller(真正的小) 的服务

推荐一本书：Building Microservice

购买地址：AMAZON的图书书评地址：https://book.douban.com/subject/25881698/将服务做小的关键点总结：每个服务要关注“业务”领域，每个服务解决一个具体问题结构上呈现“松散、耦合”架构，便于后期部署、测试、调试

“有边界”的上下文，并不需要每个服务周边的部分—其他服务、依赖服务等，团队只关注服务本身和服务的API；传统应用的需求分析需要对全局需求有了解并设计后才能开发，而微服务可以更快让团队开始每个服务都可以独立部署

需要配套思想对应的工具（如DevOps的工具等）鼓励大家使用新技术（建议：伯斯塔尔法则，做的时候要保守，接受的时候要开放）自动化的文化能在两周内重写的东西（衡量Microservice的服务小的标准）两张披萨团队（亚马逊内部思路，一个灵活敏捷的团队应该控制在10个人左右）

3.5 Microservice的实践- Netflix IPC Stack

★Netflix IPC Stack 1.0 Netflix内部的一个应用，1.0采用传统的SILOs风格的应用，不符合Microservice的设计风格

★Netflix IPC Stack 2.0 Netflix 在 IPC Stack 2.0开始抽象出了比较粗的服务，并独立部署在彼此隔离的容器中，且通过HTTP API进行交互Microservice的相关技术与云服务

4.1 容器计算技术

传统虚拟机（拥有hypervisor）会存在性能损耗，而Docker采用LXC技术取消了hypervisor，直接使用Linux Kernel，提升了性能而docker的这种快速部署和管理能力，正好和Microservice的服务快速部署吻合。

4.2 AWS上的docker运行模式有3种EC2（直接使用EC2服务中内置了docker能力的AMI启动实例来使用docker）AWS Elastic BeanStalk（利用docker技术进行封装，来自动部署弹性web应用和服务架构的托管类应用，可支持php、java、.net等语言环境）

EC2 Container Service（提供针对docker容器的可视化、流水线式的管理能力）4.3 EC2 Container ServiceECS的关键组件机群（Container Cluster） 

- 区分区域 - 相当于资源池 - 相当于容器实例的分组 - 启动时为空、动态扩容与调整容器实例（运行容器的EC2实例） - 包含一个EC2实例 - 在实例中存在一个Docker进程 - 在实例中存在一个 ECS的代理（Agent是开源的，用goLang开发）

任务（就是一个个docker 容器） - 每个实例可以设置多个任务 - 任务是作业的单位 - 允许任务分组和设置关联 - 任务运行在EC2实例中任务 定义 - 通过json来定义任务 - 包括：docker hub模板、cpu数量、内存等 

任务 调度（实现计算资源的管理） - 长期运行的服务（Long-running services） - 批量执行任务（RunTask for bach jobs） - 集成第三方调度器schedulers

4.4 Microservice的实践- Coursera（使用了ECS）4.4.1 一个mooc网站

4.4.2 Coursera的需求之前Coursera开发了一套传统的互联网应用架构，有很多程序单元，而每一个单元里面有很多服务（粒度很粗），主要的需求是可靠性：因为服务的人员比较多，所以如果应用宕机则对公司声誉2.影响大

更容易开发：互联网公司生存压力，需要快速上线更多应用满足客户需求，另一方面，小并且公式化的开发模式是必须的更快部署成本的考虑：希望投入产出比更高更高效的运维：只有1个运维人员，现有环境维护太复杂 

4.4.3 Coursera的选择之路Coursera尝试了很多方法，最后不希望自己运维和折腾了，所以选择了ECS 自己的现有技术 - 尝试过，但是不可靠 - 操作困难MESOS - 非常强大，实际操作过程中易用性差 

- 需要一直与之匹配的DevOps团队Kubernetes - 在GCE上表现的很好，其他地方就不行了（而GCE是google的IaaS平台）使用ECS - 维护成本几乎为0 - Coursera已经使用了AWS的服务，如IAM等希望继续沿用 

- 开发人员更好理解和操作（docker本身还是主机不用改变语言开发方式），学习成本低4.4.4 最终Coursera改造后的Microservice架构大量的使用ECS的work部署Microservice中的service

前端+调度器 设计 生成的请求(通过API调用 或 内部通信都通过scheduler来分配)新请求保存在 SQS 队列中根据来自其他服务的状态 而 处理请求后端设计 试图通过ECS 的API 来运行task（不是通过界面操作，更快更及时）

如果任务失败，则任务自动回滚到队列中，之后重试保持任务状态的跟踪，并更新 Cassandra数据库（一种NoSQL数据库）

4.5 AWS的Lambda(托管的、事件驱动架构的计算平台服务)特点：零管理：是一个计算平台而不是一个windows或linux，因此不需要过多的管理环境相关的东西（例如多少cpu、内存、带宽等）事件驱动：基于事件产生对代码块的自动调用

计算平台：对于开发人员来讲，就是一个计算平台，提交代码然后等待结果即可用户可以专注业务逻辑而不是基础架构：用户针对业务进行服务开发（可以使用javascript、java等）并设定好触发机制上传代码，而AWS Lambda负责后续的工作，如容量、扩展、部署、容错、监控、日志等

自动化扩展：用户仅仅负担所使用的费用，不会超过/低于资源调配细粒度的定价：价格计量单位是毫秒（单位是100ms）对于短时间任务非常有价值，没有最低消费，可以免费试用事件以不同的形态和尺寸发生：S3事件通知、DynamoDB Streams事件、Kinesis（事件流）事件、定制化事件

同步异步都可调用：针对不同的业务场景可以选择同步异步模式调用，如某些应用日志产生问题后异步响应触发lambda调用。或定制实践发生后同步触发lambda调用

基础架构的扩展性、利用率情况

4.6 Microservice的实践-AWS Lambda使用方法示例4.6.1 一个内容管理系统（CMS）具体需求包括： - 允许用户上传头像 - 需要将图片保存 - 需要为头像制作缩略图，在不同的web位置使用

4.6.2 传统情况一个CMS应用搞定所有工作，涉及的流程包括：上传头像→保存图片→将图片生成缩略图传统情况下修改任意环节（如保存图片）则需要将CMS系统重新打包然后更新4.6.2 Lambda改造情况

用户上传图片到S3中，一个新的S3对象将触发lambda函数来转换成缩略图，将缩略图保存到S3的另外一个bucket另一方面将元数据保存到DynamoDB中，当一个新的保存条目后触发一个创建ECS的task的事件去执行其他操作（如生成GIF图

）

原文：http://blog.csdn.net/qxk2001/article/details/51319210进阶阅读Stack Overflow 2016最新架构探秘Tumblr：150亿月浏览量背后的架构挑战

在线支付之风控系统架构选型