首页 文章 精选 留言 我的

精选列表

搜索[CloudQ共创征文],共1296篇文章
优秀的个人博客,低调大师

【AWS征文】AWS网络演进

我们都知道,对于企业来讲,随着业务的发展和重点不同,对网络的实际需求也是不同的,尤其是对于公有云的网络架构,随着AWS的功能完善和发展,越来越多的网络功能得以实现。本文将结合实际案例讲述如何以及为什么从DX过渡到DX gateway的 DX时期的网络方案 企业上云绝非一蹴而就的事情,这就意味着必然存在着一个本地云与公有云共同存在的时期,这就涉及到了本地IDC与云上IDC的互通问题。因我们启用业务上云的方案较早,当时的 AWS还仅有DX的功能,通过此功能我们可以使用AWS合作伙伴专线将本地IDC与AWS连接起来。具体网络架构如下: DX的出现,使得企业可以通过DX的private VIF或者 public VIF将企业的分支/本地IDC与AWS连接起来。而为了实现高可用性,一般不会仅建立一个DX通道,可能会采用如下冗余方案: 两条不同ISP的专线通过不同DX location或者DX 设备连接到AWS的方案 一条ISP专线,一根Internet+IPsec ***的方案 一条ISP专线,一根SD-WAN线路的方案 两根***线路的方案,(可以是Internet+IPsec ***与SD-WAN的组合)等等而因为对线路的时延可靠性等要求,我们当时选择了第一种方案,如下所示。 DX双专线接入时,双活的实现 因AWS DX功能比较弱,无法通过AWS侧设备实现路由的选路,这就导致我们需要通过远端局点的路由控制来实现主备路径的选择,从而使得两条路径互为备份。 如果要选择ISP A的专线为主用线路,则需要如下配置: 1.在Customer GW A上,从ISP A 的EBGP邻居接收路由时,使用route-map修改local-preference的值,将local-preference设置的大于B线路的,使得IDC本地到AWS时,优选A线路。2.同时,在Customer GW B上向B线路的EBGP邻居发布路由时,使用route-map修改AS-path属性,在AS-path后增加几个as-path,使得AWS侧接收到B线路的路由为非优选路由。3.当然,为了切换便利性,我们可以一次性写两套A、B分别为主用线路时的route-map,通过自动化工具,实现路径的一键切换。 配置参考如下: Customer GW A上: route-policy IN_EBGP_A permit node 10 if-match ip-prefix AWS apply local-preference 200 route-policy OUT_EBGP_A permit node 10 if-match ip-prefix LOCAL_IDC route-policy IN_EBGP_B permit node 10 if-match ip-prefix AWS route-policy OUT_EBGP_B permit node 10 if-match ip-prefix LOCAL_IDC Apply as-path 64512 64512 add Customer GW B上: route-policy IN_EBGP_A permit node 10 if-match ip-prefix AWS route-policy OUT_EBGP_A permit node 10 if-match ip-prefix LOCAL_IDC Apply as-path 64512 64512 add route-policy IN_EBGP_B permit node 10 if-match ip-prefix AWS apply local-preference 200 route-policy OUT_EBGP_B permit node 10 if-match ip-prefix LOCAL_IDC 经过一段时间的运行和实践,发现该方案有很多不足之处。比如,因DX功能限制,从ISP A学到的路由会向ISP B传递,从而导致路由环路或者专线路由条目超限的问题等。在多次踩坑之后,痛定思痛,进行了DX到DX GW的改造。 DX Gateway是什么 先看一下没有DX gateway(以下简称DXGW)之前,如果要互联VPC是什么样的? 有了DXGW之后,又是什么样的呢? 每个DX Gateway都是跨所有公共AWS区域存在的全局对象,这就使得所有AWS区域之间可以通过网关进行所有的通信,大大减少了VIF的数量和BGP会话的数量,同时也简化了网络结构和维护成本。 更更重要的是,多了一个DXGW,相当于在DXGW侧多了一台路由器,路由多了一跳,从ISP A学到的路由再也不会默认向ISP B发布了,一劳永逸的解决了因DX功能限制而导致的路由环路和路由条目超限的问题。 DX Gateway如何实现双路径的选路? 改造为DX GW之后,双路径的主备切换和DX时保持一致,还是要通过企业本地IDC侧CE 上BGP的选路来控制的。配置同:DX双专线接入时,双活的实现。 DX Gateway的限制 当然,如此便利的DXGW也有一些限制条件,并不是任何时候都适用,限制如下: 关联到DXGW的VGW/VPC可以属于不同的区域,但必须属于同一个AWS账户 VPC不能使用重复的IP地址段 一个DXGW最多可关联10个VIF/VGW 关联到同一个DXGW的private VIF之间不能进行数据访问 关联到同一个DXGW的VGW之间不能进行数据访问

优秀的个人博客,低调大师

共创“拍照翻译(生活服务)

简介 本章采用了阿里云云市场通用文字识别API服务对图片进行文字转换,并采用阿里云云市场通用在线翻译API服务对文字进行翻译,支持的语言包括英文,中文等。 环境要求 Window/ Mac / Linux python2.7 pip Django1.11.x 安装 1.Python2.7安装,根据系统在https://www.python.org/getit/ 找到相应的版本进行下载。 2. pip安装, 可在 https://github.com/pypa/pip 下载代码进行安装。 3. django安装, 输入命令 python -m pip install "django<2" 使用 代码存放在http://ojehdvqwi.bkt.clouddn.com/aliyu.zip进行下载 一. 调试阿里云云市场通用文字识别API服务 test文件夹下有两个测试文件test.py及test1.py test.py 用来测试通用文字识别API服务,在目录下运行 python test/test.py,正常情况下返回 {“status":"0","msg":"ok","result":["Query"]} test1.py 用来测试在线翻译API服务,运行 python test/test1.py,正常情况下返回{"status":"0","msg":"ok","result":{"type":"google","from":"en","to":"zh-cn","text":"i love you","result":"我爱你"}} 如果上述两个测试文件测试成功后,说明后端调用阿里云api服务是成功的。 二、部署服务器环境 拷贝源代码在自己的的目录下,并在与 manage.py 同目录下运行 python manage.py runserver,打开http://127.0.0.1:8000/index,如果打开下述页面说明成功 三、样品演示 http://ojehdvqwi.bkt.clouddn.com/%E5%85%B1%E5%88%9B%E6%8B%8D%E7%85%A7%E7%BF%BB%E8%AF%91.mov 四、安装教程 http://ojehdvqwi.bkt.clouddn.com/%E9%83%A8%E7%BD%B2%E6%9C%8D%E5%8A%A1%E5%99%A8.mov

优秀的个人博客,低调大师

【AWS征文】ECS让容器编排更轻松

Amazon Elastic Container Service (Amazon ECS) 是Amazon专有的、高度可扩展的高性能容器管理服务,可轻松运行、停止和管理集群上的 Docker容器。 使用ECS,不再需要安装、运维和扩展自己的集群管理基础设施。只需简单的 API 调用便可以启动和停止Docker应用程序,查询集群状态等。可以根据资源需求、隔离策略和可用性要求来安排容器在集群中的位置。ECS集成了Amazon Elastic Container Registry、Elastic Load Balancing、Elastic Block Store、Elastic Network Interfaces、Virtual Private Cloud、IAM 和 CloudTrail,可提供运行各种容器化应用程序或服务的完整解决方案。 ECS是一个久经考验的解决方案,已应用于许多其他 AWS 服务,比如Amazon SageMaker 和 Amazon Lex。这足以证明ECS的安全性、可靠性、可用性,可用于生产环境。 启动类型 ECS支持两种启动类型:Fargate和EC2。 Fargate 启动类型 Fargate 启动类型无需配置和管理底层基础设施,只需定义任务(相当于Kubernetes的Pod),指定CPU、内存、网络、IAM策略等,即可运行容器化的应用程序。 EC2 启动类型 EC2 启动类型允许在自己管理的 EC2 实例集群上运行容器化的应用程序。 您可以使用 Fargate 启动类型启动服务或任务,运行在ECS 管理的无服务器基础设施上,不必管理 Amazon EC2 实例服务器或集群。若要进行更多控制,可以使用 EC2 启动类型。 下面讲解利用Fargate 启动类型部署Angular 9集成Spring Boot 2详解中的Spring Boot和Angular应用。 创建Docker Image Spring Boot项目的Dockerfile文件: Dockerfile.spring FROM openjdk:8-jdk-slim WORKDIR app ARG APPJAR=target/heroes-api-1.0.0.jar COPY ${APPJAR} app.jar ENTRYPOINT ["java","-jar","app.jar"] Angular项目的Dockerfile文件: Dockerfile.angular FROM httpd:2.4 ARG DISTPATH=./dist/ ARG CONFFILE=./heroes-httpd.conf COPY ${DISTPATH} /usr/local/apache2/htdocs/ COPY ${CONFFILE} /usr/local/apache2/conf/httpd.conf 以部署到Apache为例,运行以下命令获取httpd.conf: docker run --rm httpd:2.4 cat /usr/local/apache2/conf/httpd.conf > heroes-httpd.conf 修改配置文件,启用proxy_module、proxy_http_module、rewrite_module,然后添加如下内容: ProxyPreserveHost on ProxyPass "/api" "http://127.0.0.1:8080/api" ProxyPa***everse "/api" "http://127.0.0.1:8080/api" RewriteEngine on RewriteRule ^/$ /en/index.html # If an existing asset or directory is requested go to it as it is RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR] RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d RewriteRule ^ - [L] # If the requested resource doesn't exist, use index.html RewriteRule ^/zh /zh/index.html RewriteRule ^/en /en/index.html 我们将在一个任务中包含这两个image,使用apache代理后台地址。 构建Image运行如下命令构建Image: docker build --build-arg APPJAR=heroes-api-1.0.0.jar -f Dockerfile.spring -t heroes-api . docker build -f Dockerfile.angular -t heroes-web . 推送Image到ECR Amazon Elastic Container Registry (Amazon ECR) 是一项Docker Container Registry服务,可让开发人员轻松存储、管理和部署 Docker 容器映像。 创建ECR存储库 首先创建两个ECR存储库,可以从控制台创建,也可以运行如下AWS CLI命令: aws ecr create-repository --repository-name heroes/heroes-api aws ecr create-repository --repository-name heroes/heroes-web 登录ECR存储库 执行如下命令: `aws ecr get-login --no-include-email` 或 aws ecr get-login-password | docker login --username AWS --password-stdin 888888888888.dkr.ecr.cn-north-1.amazonaws.com.cn 标记image docker tag heroes-api:latest 888888888888.dkr.ecr.cn-north-1.amazonaws.com.cn/heroes/heroes-api:latest docker tag heroes-web:latest 888888888888.dkr.ecr.cn-north-1.amazonaws.com.cn/heroes/heroes-web:latest 推送Image docker push 888888888888.dkr.ecr.cn-north-1.amazonaws.com.cn/heroes/heroes-api:latest docker push 888888888888.dkr.ecr.cn-north-1.amazonaws.com.cn/heroes/heroes-web:latest 创建集群 Amazon ECS 集群是任务或服务的逻辑分组,可以在一个账户中创建多个集群以保持资源独立。 创建Fargate集群非常简单,进入ECS集群控制台,点击“创建集群”,选择“仅限联网”集群模板,点击“下一步”,然后输入集群名称"heroes",点击“创建”即可。 创建任务定义 任务定义类似于应用程序的蓝图,需要任务定义才能在Amazon ECS 中运行 Docker 容器。 可在Fargate任务定义中指定的一些参数: 用于任务的Docker Image 任务的CPU和内存数量 任务的日志记录配置 任务使用的 IAM 角色 任务中用于容器的数据卷 容器在启动时应运行的命令 执行以下步骤创建任务定义: 进入ECS 任务定义控制台,点击创建任务定义 选择FARGATE启动类型,点击下一步 在配置任务和容器定义页面中,输入任务定义名称(heroes),选择任务角色,配置任务内存、CPU 内存、CPU的有效的组合 CPU 值 内存值 (MiB) 256 (.25 vCPU) 512 MB、1 GB、2 GB 512 (.5 vCPU) 1 GB、2 GB、3 GB、4 GB 1024 (1 vCPU) 2 GB、3 GB、4 GB、5 GB、6 GB、7 GB、8 GB 2048 (2 vCPU) 4GB 到 16GB(以1GB为增量) 4096 (4 vCPU) 8GB 到 30GB(以1GB为增量) 容器存储与共享卷Fargate 启动类型,任务的最大容器存储为10GB,多个容器使用的共享卷的最大大小为4GB。若要添加共享卷,在卷配置部分点击“添加卷”,输入卷名称后点击“添加”即可。注意,任务存储是短暂存储。Fargate 任务停止后,该存储将被删除。 添加容器接下来,在容器定义部分点击“添加容器”按钮,添加heroes-api和heroes-web容器:在高级容器配置下部的“存储和日志记录”部分可以添加挂载点和配置日志:默认,Fargate任务记录日志到CloudWatch Log,可以设置每个容器的日志组名称、日志流前缀等。 最后,点击“创建”,完成任务定义。 创建Service 服务可在 Amazon ECS 集群中同时运行和管理指定数量的任务定义实例。如果任务出于任何原因失败或停止,服务计划程序将启动另一个任务定义实例来替换它并根据所用的计划策略在服务中保留预期数量的任务。 除了在服务中保留预期数量的任务之外,还可选择借助负载均衡器运行服务。负载均衡器将在与服务关联的各个任务间分配流量。 在ECS控制台,从集群和任务定义均可创建服务。以任务定义为例,步骤如下: 配置基本参数选中heroes任务定义,然后点击操作 -> 创建服务,在配置服务页面填充以下参数: 启动类型:FARGATE 集群:heroes 服务名称:heroes 任务数:1 部署类型:滚动更新 点击下一步。 网络配置在VPC 和安全组部分,选择集群 VPC、子网。默认会自动生成一个安全组名称,您可以点击编辑,修改安全组名称,或者选择一个现有安全组。若选择新建安全组,默认配置了80端口的入站规则。我们使用ELB,不需要公有IP,将自动分配公有 IP选项设为DISABLED。 负载均衡我们新创建一个ALB,先不必创建目标群组。 负载均衡器类型: Application Load Balancer 负载均衡器名称:选择前面新建的ALB 选择一个容器: heroes-web:80:80,然后点击“添加到负载均衡器”,输入以下参数:生产侦听器端口:新建 80生产侦听器协议:HTTP目标组名称:新建 ecs-heroes目标组协议:HTTP 设置 Auto Scaling服务 Auto Scaling:请勿调整服务的预期计数 审核检查无误后点击创建服务。 返回到集群界面,可以看到heroes集群含有一个服务,一个正在运行的任务。 服务限制在集群任务界面,我们若停止当前任务,稍后会自动重启新任务,同时会自动更新ELB的目标群组。 Amazon ECS 服务计划程序包含限制服务任务在反复启动失败后再启动的频率逻辑。 如果一个 ECS 服务的任务总是无法进入 RUNNING 状态(直接从 PENDING 跳到 STOPPED),则后续重启尝试间隔的时间会逐渐拉长,最多达到 15 分钟 访问服务进入heroes集群 -> 任务,点击任务,进入任务详细信息页面,可以看到任务的私有 IP 地址。在内部网络中,可以使用私有IP访问每个任务部署的应用。公网则通过ELB访问服务。 日志配置 awslogs 默认,Fargate任务使用awslogs日志驱动程序,记录日志到CloudWatch Log。 awslogs 日志驱动程序选项 选项 必须 说明 awslogs-create-group 否 自动创建日志组,IAM 策略必须包含 logs:CreateLogGroup 权限。默认值false awslogs-region 是 日志驱动程序应将Docker 日志发送到的区域 awslogs-group 是 日志驱动程序将日志流发送到的日志组 awslogs-stream-prefix 是 日志流前缀,日志流格式:prefix-name/container-name/ecs-task-id awslogs-datetime-format 否 以 Python strftime 格式定义多行开始位置模式 awslogs-multiline-pattern 否 使用正则表达式定义多行开始位置模式 说明:如果同时配置了 awslogs-datetime-format 和 awslogs-multiline-pattern, awslogs-datetime-format选项优先。多行日志记录对所有日志消息执行正则表达式解析和匹配,这可能会对日志记录性能产生负面影响。 FireLens集成 FireLens for Amazon ECS 可将日志路由到 AWS 服务或 AWS 合作伙伴网络(APN)目标位置,以进行日志存储和分析。FireLens 可与 Fluentd 和 Fluent Bit 结合使用。AWS 提供了 Fluent Bit 映像以及用于 CloudWatch Logs 和 Kinesis Data Firehose 的插件,也可以使用自己的 Fluentd 或 Fluent Bit 映像。 Fluent Bit 和Fluentd是两个日志归集工具,Fluent Bit 插件更节省资源、效率更高,建议使用 Fluent Bit 作为日志路由器。 选中我们前面创建的任务,点击“创建新修订”,启用FireLens 集成: 如上图,选中fluentbit后会自动填充映像地址,点击应用将自动添加log_router容器。 注意,使用CloudWatch插件,任务角色必须拥有CreateLogGroup、CreateLogStream、DescribeLogStreams、PutLogEvents权限;使用AmazonKinesisFirehose插件必须拥有 "firehose:PutRecordBatch"权限。 配置log_router { "essential": true, "image": "128054284489.dkr.ecr.cn-north-1.amazonaws.com.cn/aws-for-fluent-bit:latest", "name": "log_router", "firelensConfiguration": { "type": "fluentbit" }, "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/firelens", "awslogs-region": "cn-north-1", "awslogs-create-group": "true", "awslogs-stream-prefix": "firelens" } }, "memoryReservation": 50 } Log Router日志使用awslogs驱动,记录到CloudWatch: 下面我们利用Fluent Bit将日志分别转发到CloudWatch Logs和Kinesis Data Firehose。 将日志转发到 CloudWatch Logs 修改容器heroes-api的日志配置,驱动程序选择"awsfirelens",日志选项 "Name"值设为"cloudwatch",启用CloudWatch Logs插件,其它配置如下: { "essential": true, "image": "888888888888.dkr.ecr.cn-north-1.amazonaws.com.cn/heroes/heroes-api:latest", "name": "heroes-api", "logConfiguration": { "logDriver": "awsfirelens", "options": { "Name": "cloudwatch", "region": "cn-north-1", "log_group_name": "/ecs/heroes-api", "log_stream_prefix": "from-fluent-bit", "auto_create_group": "true" } } } 任务修改完毕后,点击“创建”保存任务定义。 返回到集群控制台,选中我们创建的服务,点击“更新”,然后选择最新的任务定义,选中“强制实施新部署”,一步步保存服务。 服务更新成功后将创建新的任务,进入Cloud Watch控制台查看日志,日志格式如下: { "container_id": "cda4f603d8e485d48fd7e1a77b3737026221c165b8f6d582ed78bd947a12b911", "container_name": "/ecs-heroes-2-heroes-api-c2f3d4a8bdbcf3f9e601", "ecs_cluster": "arn:aws-cn:ecs:cn-north-1:888888888888:cluster/isd", "ecs_task_arn": "arn:aws-cn:ecs:cn-north-1:888888888888:task/078dd364-28b6-4650-b294-5eac6b39d08f", "ecs_task_definition": "heroes:2", "log": " /\\\\ / ___'_ __ _ _(_)_ __ __ _ \\ \\ \\ \\", "source": "stdout" } 可以看到,日志添加了新的标识字段:container_id、container_name、ecs_cluster、ecs_task_arn、ecs_task_definition和source。 在任务定义时,点击“通过JSON配置”,设置fluentbit的选项enable-ecs-log-metadata为false,可以禁用上面三个ecs元数据: "firelensConfiguration": { "type": "fluentbit", "options": { "enable-ecs-log-metadata": "false" } } 在容器的日志配置中,增加log_key选项,可以仅转发log项: "log_key": "log" CloudWatch Logs插件支持的选项: region: AWS region log_group_name: CloudWatch日志组名称 log_stream_name: CloudWatch日志流名称 log_stream_prefix: 日志流名称前缀,与log_stream_name选项不兼容 log_key: 默认,整个日志记录都发送到CloudWatch,如果指定key name,仅发送指定项到CloudWatch log_format: 日志格式 auto_create_group: 自动创建日志组,默认值false 将日志转发到 Amazon Kinesis Data Firehose Kinesis Data Firehose插件支持的选项: region: AWS region delivery_stream: Kinesis Data Firehose 传输流的名字 data_keys: 默认,整个日志记录都发送到Kinesis, 如果指定key name(s),仅发送指定项到Kinesis。 多个名字以逗号分隔。 Kinesis Data Firehose传输流可以将日志发送到Amazon S3、Amazon Redshift和Amazon Elasticsearch Service。 以S3为例,我们先创建到S3的传输流heroes-web-log,然后修改容器heroes-web的日志配置,驱动程序选择"awsfirelens",日志选项 "Name"值设为"firehose",启用Kinesis Data Firehose插件,其它配置如下: { "essential": true, "image": "888888888888.dkr.ecr.cn-north-1.amazonaws.com.cn/heroes/heroes-web:latest", "name": "heroes-web", "logConfiguration": { "logDriver":"awsfirelens", "options": { "Name": "firehose", "region": "cn-north-1", "delivery_stream": "heroes-web-log", "data_keys": "log" } }, "memoryReservation": 100 } 保存任务定义、更新服务后即可到S3查看日志了。 ECS vs EKS Amazon Elastic Kubernetes Service (Amazon EKS)是全托管的Kubernetes服务,运行开源的 Kubernetes来部署、管理和扩展容器化应用程序。EKS无需使用Kubernetes控制平面,消除了运行 Kubernetes 的重大操作负担,使得可以专注于构建应用程序而不是管理 AWS 基础设施。EKS可跨多个 AWS 可用区运行,与 Kubernetes 兼容,可以使用 Kubernetes 社区提供的所有现有插件和工具,所有标准 Kubernetes 环境中运行的应用程序均可轻松迁移到EKS。 通用性ECS是AWS专有技术,而 EKS 则运行开源的 Kubernetes。因此,如果您的部署环境不局限于AWS,比如可能部署到Google GKE(Google Kubernetes Engine)、Microsoft AKS(Azure Kubernetes Service)或标准Kubernetes,应选用EKS。 简易性ECS是一个开箱即用的解决方案,可通过 AWS 控制台轻松部署。EKS有点复杂,需要更多的配置,需要更多的专业知识。 价格ECS不收取任何额外费用,只需为容器使用的计算资源付费。EKS集群每小时需支付 0.688 CNY(可以利用 Kubernetes 命名空间和 IAM 安全策略,使用一个EKS 集群运行多个应用程序),用于运行 Kubernetes 工作节点的 AWS 资源需按实际使用量付费。 经过测试与对比ECS、EKS、Kubernetes三种容器编排解决方案,笔者工作中选用了ECS,ECS完全满足项目需求,让部署更轻松、运维更轻松、成本更轻松。 参考文档 Amazon Elastic Container Service 文档

优秀的个人博客,低调大师

【AWS征文】AWS 数据加密知识点

一、S3 加密 服务端加密 服务器端加密是由接收数据的应用程序或服务在数据目的地对数据进行加密。Amazon S3 在将您的数据写入数据中心内的磁盘时会在对象级别上加密这些数据,并在您访问这些数据时为您解密这些数据。只要您验证了您的请求并且拥有访问权限,您访问加密和未加密对象的方式就没有区别。例如,如果您使用预签名的 URL 来共享您的对象,那么对于加密和解密对象,该 URL 的工作方式是相同的。此外,在您列出存储桶中的对象时,列表 API 会返回所有对象的列表(无论对象是否加密)。 注意您不能对同一个对象应用不同类型的服务器端加密。 您有三个互斥选项,具体取决于您选择如何管理加密密钥: 具有 Amazon S3 托管密钥的服务器端加密 (SSE-S3) 当您使用具有 Amazon S3 托管密钥的服务器端加密 (SSE-S3) 时,每个对象均使用唯一密钥加密。作为额外的保护,它将使用定期轮换的主密钥对密钥本身进行加密。Amazon S3 服务器端加密使用可用的最强数据块密码之一(即 256 位高级加密标准 (AES-256))来加密您的数据。有关更多信息,请参阅使用具有 Amazon S3 托管加密密钥的服务器端加密 (SSE-S3) 保护数据。 每个对象使用唯一数据秘钥加密 在 AWS Key Management Service 中存储客户主密钥 (CMK) 的服务器端加密 (SSE-KMS) 在 AWS Key Management Service 中存储客户主密钥 (CMK) 的服务器端加密 (SSE-KMS) 与 SSE-S3 类似,使用该服务具有一些额外的好处,但也要额外收取费用。使用 CMK 需要单独的权限,该密钥可进一步防止未经授权地访问 Amazon S3 中的对象。SSE-KMS 还向您提供审核跟踪,显示您的 CMK 的使用时间和使用者。此外,您还可以创建和管理客户托管 CMK,或者使用您、服务和区域独有的 AWS 托管 CMK。有关更多信息,请参阅使用具有 AWS Key Management Service 中存储的 CMK 的服务器端加密 (SSE-KMS) 保护数据。 每个对象使用唯一数据秘钥加密 具有客户提供密钥的服务器端加密 (SSE-C) 使用具有客户提供密钥的服务器端加密 (SSE-C) 时,您管理加密密钥,而 Amazon S3 管理加密(在它对磁盘进行写入时)和解密(在您访问您的对象时)。有关更多信息,请参阅通过使用客户提供的加密密钥的服务器端加密 (SSE-C) 保护数据。 所有对象使用相同的秘钥加密(客户端提供的) 客户端加密 客户端加密 是在将数据发送到 Amazon S3 之前加密数据的行为。要启用客户端加密,您可以选择以下方法: 使用 AWS KMS 中存储的 CMK 在上传对象时 — 通过使用客户主密钥 (CMK) ID,客户端先向 AWS KMS 发送请求以获取可用于加密对象数据的 CMK。AWS KMS 返回两个随机生成的数据密钥版本: 客户端用于加密对象数据的数据密钥的纯文本版本 客户端将作为对象元数据上传到 Amazon S3 的同一数据密钥的密码 blob 下载对象时 — 客户端首先从 Amazon S3 下载加密的对象以及作为对象元数据存储的数据密钥的密码 blob 版本。然后,客户端将密码 blob 发送到 AWS KMS 以获取密钥的纯文本版本,以便让客户端解密对象数据。 客户端将为其上传的每个对象获取一个唯一的数据密钥。 使用在应用程序中存储的主密钥 上传对象时 — 将客户端主密钥提供给 Amazon S3 加密客户端。该客户端仅使用该主密钥来加密客户端随机生成的数据加密密钥。该过程的工作方式如下所示: Amazon S3 加密客户端在本地生成一个一次性对称密钥 (也称为“数据加密密钥”或“数据密钥”)。它使用数据密钥加密单个 Amazon S3 对象的数据。该客户端将为每个对象生成一个单独的数据密钥。 该客户端使用您提供的主密钥来加密数据加密密钥。客户端会将加密的数据密钥及其材料说明作为对象元数据的一部分上传。该客户端利用材料描述来确定要用于解密的客户端主密钥。 该客户端将加密数据上传到 Amazon S3 并在 Amazon S3 中将加密数据密钥保存为对象元数据 (x-amz-meta-x-amz-key)。 下载对象时 — 该客户端从 Amazon S3 下载加密的对象。通过使用对象元数据中的材料说明,该客户端将确定要用于解密数据密钥的主密钥。该客户端将使用该主密钥解密数据密钥,然后使用该数据密钥对对象进行解密。 您提供的客户端主密钥可以是对称密钥,也可以是公有/私有密钥对。 SSE-KMS 需要额外的费用,使用 SSE-S3/SSE-C 免费 二、KMS 秘钥自动轮换方式 备用密钥管理。AWS KMS 会保留 CMK 的所有备用密钥,即使密钥轮换处于禁用状态。只有删除 CMK 后才会删除备用密钥。如果使用 CMK 进行加密,AWS KMS 会使用当前的备用密钥。如果使用 CMK 进行解密,AWS KMS 会使用加密时所用的备用密钥。 启用和禁用密钥轮换。默认情况下,客户管理的 CMK 的自动密钥轮换处于禁用状态。当您启用(或重新启用)密钥轮换时,AWS KMS 会在启用日期 365 天后自动轮换 CMK,并在此后每隔 365 天轮换一次。 已禁用的 CMK。 禁用 CMK 后,AWS KMS 不会对它进行轮换。但是,密钥轮换状态不会发生改变,并且在 CMK 处于禁用状态时不能对其进行更改。重新启用 CMK 后,如果备用密钥已超过 365 天,AWS KMS 会立即轮换,并在此后每隔 365 天轮换一次。如果备用密钥少于 365 天,AWS KMS 会恢复原始密钥轮换计划。 待删除的 CMK。 对于待删除的 CMK,AWS KMS 不会对它进行轮换。密钥轮换状态设为 false,处于待删除状态时不能更改。如果删除被取消,将恢复之前的密钥轮换状态。如果备用密钥已超过 365 天,AWS KMS 会立即轮换,并在此后每隔 365 天轮换一次。如果备用密钥少于 365 天,AWS KMS 会恢复原始密钥轮换计划。 AWS 托管 CMK。 对于 AWS 托管 CMK,您无法管理其密钥轮换。AWS KMS 每隔三年(1095 天)自动轮换一次 AWS 托管 CMK。 AWS 拥有的 CMK。 对于 AWS 拥有的 CMK,您无法管理其密钥轮换。AWS 拥有的 CMK 的密钥轮换策略由创建和管理 CMK 的 AWS 服务确定。有关详细信息,请参阅服务的用户指南或开发人员指南中的静态加密 主题。 AWS 服务。在 AWS 服务中,您可以在用于服务器端加密的 客户托管 CMK 上启用自动密钥轮换。年度轮换是透明的,并与 AWS 服务兼容。 监控密钥轮换。 当 AWS KMS 自动轮换 AWS 托管 CMK 或客户托管 CMK 的密钥材料时,会将 KMS CMK Rotation (KMS CMK 轮换) 事件写入 Amazon CloudWatch Events 中。您可以通过该事件验证 CMK 是否已轮换。 不支持的 CMK 类型。 以下类型的 CMK 不 支持自动密钥轮换,但您可以手动轮换这些 CMK。

优秀的个人博客,低调大师

【AWS征文】AWS Lambda 借助 Serverless Framework,迅速起飞

前言 微服务架构有别于传统的单体式应用方案,我们可将单体应用拆分成多个核心功能。每个功能都被称为一项服务,可以单独构建和部署,这意味着各项服务在工作时不会互相影响 这种设计理念被进一步应用,就变成了无服务(Serverless)。「无服务」看似挺荒唐的,其实服务器依旧存在,只是我们不需要关注或预置服务器。这让开发人员的精力更集中——只关注功能实现 Serverless 的典型便是 AWS Lambda AWS Lambda 如果你是 Java 开发人员,你应该听说过或使用过 JDK 1.8 里面的 Lambda,但是 AWS 中的 Lambda 和 JDK 中的 Lambda 没有任何关系 这里的 AWS Lambda 就是一种计算服务,无需预置或管理服务器即可运行代码,借助 Lambda,我们几乎可以为任何类型的应用程序或后端服务运行代码,而且完全无需管理,我们要做的只是上传相应的代码,Lambda 会处理运行和扩展 HA 代码所需的一切工作 说的直白一点 Lambda 就好比实现某一个功能的方法 (现实中,通常会让 Lambda 功能尽可能单一),我们将这个方法做成了一个服务供调用 到这里你可能会有个困惑,Lambda 既然就是一个「方法」,那谁来调用?或怎么来调用呢? 如何调用 Lambda 为了回答上面这个问题,我们需要登陆到 AWS,打开 Lambda 服务,然后创建一个 Lambda Function (hello-lambda) Lambda 既然是个方法,就要选择相应的 Runtime 环境,如下图所示,总有一款适合你的(最近在用 Node.js, 这里就用这个吧) 点击右下角的 Create function 按钮进入配置页面 在上图红色框线的位置就可以配置出发 Lambda 的触发器了,点击 Add trigger 从上图可以看出,AWS 内置的很多服务都可以触发 Lambda,我在工作中常用的有: API Gateway (一会的 demo 会用到,也是最常见的调用方式) ALB - Application Loac Balancer CloudFront DynamoDB S3 SNS - Simple Notification Service SQS - Simple Queue Service 上面只是 AWS 内置的一些服务,向下滑动,你会发现,你也可以配置很多非 AWS 的事件源 到这里,上面的问题你应该已经有了答案了。这里暂时先无需任何 trigger,先点击右上角的 Test 测试一下 Lambda 一个简单的 Lambda Function 就实现了,红色框线的 response 只是告诉大家,每个请求都会有相应的 Request ID,更有 START/END 标识快速定位 Log 内容 (可以通过 CloudWatch 查看,这里暂不展开说明) 你也可能已经开始发散你的思维了,如何运用 AWS Lambda,其实在 AWS 官网有很多样例: 经典案例 比如为了适应多平台图片展示,一张原始图片上传到 S3 后,会通过 Lambda resize 适应不同平台大小的图片 比如使用 AWS Lambda 和 Amazon API Gateway 构建后端,以验证和处理 API 请求,当某一个用户发布一条动态,订阅用户将收到相应的通知 接下来我们就用 Lambda 实现经典的分布式订单服务案例 订单服务 Demo 为了增强用户使用体验,或者为了提升程序吞吐量,亦或是为了架构设计程序解耦,考虑到以上这些情况,我们通常都会借助消息中间件来完成 假设有一常见场景,用户下订单时如果选择开具发票,则需要调用发票服务,很显然调用发票服务不是程序运行的关键路径,这种场景,我们就可以通过消息中间件来解耦。这里有两个服务: 订单服务 发票服务 如果用 Lambda 来实现两个服务,整体设计思想就是这样滴: 现实中,我们不可能在 AWS console 通过点击按钮来创建各个服务的,在 AWS 实际开发中, 我们通过写 CloudFormation Template (以下会简称 CFT,其实就是一种 YAML 或者 JSON 格式的定义)来创建相关 AWS 服务,如果上述这个 Demo,从图中可以看出,我们要创建的服务还是非常多的: Lambda * 2 API Gateway SQS 如果写 AWS 原生的 CFT,要实现的内容还是挺多的 但是...... 懒惰的程序员总是能带来很多惊喜 Serverless Framework 写 JDBC 麻烦,就有了各种持久层框架的出现,同样写 AWS 原生 CFT 麻烦,就有了 Serverless Framework (以下会简称 SF)的出现帮助我们定义相关 Serverless 组件 (顺便问一下,GraphQL 你们有在用吗?) SF 不但简化了 AWS 原生 CFT 的编写,还简化了跨云服务的定义,就好比设计模式当中的 Facade,在上面建立了一层门面,隐藏了底部不同服务的细节,降低了跨云并用云的门槛,目前支持的云服务有下面这些 这里暂时不会对 SF 展开深入的说明,在我们的 demo 中只不过是要应用 SF 来定义 安装 Serverless Framework 如果你有安装 Node,那只需要一条 npm 命令全局安装即可: npm update -g serverless 安装过后检查一下安装版本是否成功 sls -version 配置 Serverless Framework 由于要使用 AWS 的 Lambda,所以要对 SF 做基本的配置,至少要让 SF 有权限创建 AWS 服务,当你创建一个 AWS 用户时,你可以获取 AK 「access_key_id」和 SK 「secret_access_key」(不是 SKII 哦),其实就是一种用户名和密码形式 然后通过下面一条命令添加配置就可以了: serverless config credentials --provider aws --key 1234 --secret 5678 --profile custom-profile --provider 云服务商 --key 你的AK --secret 你的SK --profile 如果你有多个账户时,你可以添加这个 profile 做快速区分 运行上述命令后,就会在 ~/.aws/目录创建一个名为 credentials 的文件存储上述配置,就像这样: 到这里准备工作就都完成了,开始写我们的定义就好了 创建 Serverless 应用 通过下面一条命令创建 serverless 应用 sls create --template aws-nodejs --path ./demo --name lambda-sqs-lambda --template 指定创建的模版 --path 指定创建的目录 --name 指定创建的服务名称 运行上述命令后,进入 demo 目录就是下面这个结构和内容了 ➜ demo tree . ├── handler.js └── serverless.yml 0 directories, 2 files 因为我们是用 Node.js 来编写 Serverless 应用,同样在 demo 目录下执行下面命令来初始化该目录,因为我们后面要用到两个 npm package npm init -y 现在的结构是这样的(其实就多了一个 package.json): ➜ demo tree . ├── handler.js ├── package.json └── serverless.yml 0 directories, 3 files 至此,准备工作都已就绪,接下来就在 serverless.yml 中写相应的定义就可以了 (门槛很低:按照相应的 key 写 YAML 即可,是不是很简单?),打开 serverless.yml 文件来看一下,瞬间懵逼? # Welcome to Serverless! # # This file is the main config file for your service. # It's very minimal at this point and uses default values. # You can always add more config options for more control. # We've included some commented out config examples here. # Just uncomment any of them to get that config option. # # For full config options, check the docs: # docs.serverless.com # # Happy Coding! service: lambda-sqs-lambda # app and org for use with dashboard.serverless.com #app: your-app-name #org: your-org-name # You can pin your service to only deploy with a specific Serverless version # Check out our docs for more details # frameworkVersion: "=X.X.X" provider: name: aws runtime: nodejs12.x # you can overwrite defaults here # stage: dev # region: us-east-1 # you can add statements to the Lambda function's IAM Role here # iamRoleStatements: # - Effect: "Allow" # Action: # - "s3:ListBucket" # Resource: { "Fn::Join" : ["", ["arn:aws:s3:::", { "Ref" : "ServerlessDeploymentBucket" } ] ] } # - Effect: "Allow" # Action: # - "s3:PutObject" # Resource: # Fn::Join: # - "" # - - "arn:aws:s3:::" # - "Ref" : "ServerlessDeploymentBucket" # - "/*" # you can define service wide environment variables here # environment: # variable1: value1 # you can add packaging information here #package: # include: # - include-me.js # - include-me-dir/** # exclude: # - exclude-me.js # - exclude-me-dir/** functions: hello: handler: handler.hello # The following are a few example events you can configure # NOTE: Please make sure to change your handler code to work with those events # Check the event documentation for details # events: # - http: # path: users/create # method: get # - websocket: $connect # - s3: ${env:BUCKET} # - schedule: rate(10 minutes) # - sns: greeter-topic # - stream: arn:aws:dynamodb:region:XXXXXX:table/foo/stream/1970-01-01T00:00:00.000 # - alexaSkill: amzn1.ask.skill.xx-xx-xx-xx # - alexaSmartHome: amzn1.ask.skill.xx-xx-xx-xx # - iot: # sql: "SELECT * FROM 'some_topic'" # - cloudwatchEvent: # event: # source: # - "aws.ec2" # detail-type: # - "EC2 Instance State-change Notification" # detail: # state: # - pending # - cloudwatchLog: '/aws/lambda/hello' # - cognitoUserPool: # pool: MyUserPool # trigger: PreSignUp # - alb: # listenerArn: arn:aws:elasticloadbalancing:us-east-1:XXXXXX:listener/app/my-load-balancer/50dc6c495c0c9188/ # priority: 1 # conditions: # host: example.com # path: /hello # Define function environment variables here # environment: # variable2: value2 # you can add CloudFormation resource templates here #resources: # Resources: # NewResource: # Type: AWS::S3::Bucket # Properties: # BucketName: my-new-bucket # Outputs: # NewOutput: # Description: "Description for the output" # Value: "Some output value" 乍一看,你可能觉得眼花缭乱,其实这是一个相对完整的 Lambda 配置全集,我们不需要这么详细的内容,不过这个文件作为我们的参考 接下来我们就定义 demo 所需要的一切 (关键注释已经写在代码中) service: name: lambda-sqs-lambda # 定义服务的名称 provider: name: aws # 云服务商为 aws runtime: nodejs12.x # 运行时 node 的版本 region: ap-northeast-1 # 发布到 northeast region,其实就是东京 region stage: dev # 发布环境为 dev iamRoleStatements: # 创建 IAM role,允许 lambda function 向队列发送消息 - Effect: Allow Action: - sqs:SendMessage Resource: - Fn::GetAtt: [ receiverQueue, Arn ] functions: # 定义两个 lambda functions order: handler: app/order.checkout # 第一个 lambda function 程序入口是 app 目录下的 order.js 里面的 checkout 方法 events: # trigger 触发器是 API Gateway 的方式,当接收到 /order 的 POST 请求时触发该 lambda function - http: method: post path: order invoice: handler: app/invoice.generate # 第二个 lambda function 程序入口是 app 目录下的 invoice.js 里面的 generate 方法 timeout: 30 events: # trigger 触发器是 SQS 服务,消息队列有消息时触发该 lambda function 消费消息 - sqs: arn: Fn::GetAtt: - receiverQueue - Arn resources: Resources: receiverQueue: # 定义 SQS 服务,也是 Lambda 需要依赖的服务 Type: AWS::SQS::Queue Properties: QueueName: ${self:custom.conf.queueName} # package: # exclude: # - node_modules/** custom: conf: ${file(conf/config.json)} # 引入外部定义的配置变量 config.json 内容仅仅定义了 queue 的名称,只是为了说明配置的灵活性 { "queueName": "receiverQueue" } 因为我们要模拟订单的生成,这里用 UUID 来模拟订单号, 因为我们要调用 AWS 服务API,所以要使用 aws-sdk, 所以要安装这两个 package (这两个理由够充分吗?) { "name": "lambda-sqs-lambda", "version": "1.0.0", "description": "demo for lambda", "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "license": "MIT", "dependencies": { "uuid": "^8.1.0" }, "devDependencies": { "aws-sdk": "^2.6.15" } } 接下来,我们就可以编写两个 Lambda function 的代码逻辑了 Order Lambda Function 订单服务很简单,接收一个下单请求,下单成功后快速返回给用户,同时将订单下单成功的消息发送到 SQS 中,供下游发票服务开具发票使用 'use strict'; const config = require('../conf/config.json') const AWS = require('aws-sdk'); const sqs = new AWS.SQS(); const { v4: uuidv4 } = require('uuid'); module.exports.checkout = async (event, context, callback) => { console.log(event) let statusCode = 200 let message if (!event.body) { return { statusCode: 400, body: JSON.stringify({ message: 'No order body was found', }), }; } const region = context.invokedFunctionArn.split(':')[3] const accountId = context.invokedFunctionArn.split(':')[4] const queueName = config['queueName'] // 组装 SQS 服务的 URL const queueUrl = `https://sqs.${region}.amazonaws.com/${accountId}/${queueName}` const orderId = uuidv4() try { // 调用 SQS 服务 await sqs.sendMessage({ QueueUrl: queueUrl, MessageBody: event.body, MessageAttributes: { orderId: { StringValue: orderId, DataType: 'String', }, }, }).promise(); message = 'Order message is placed in the Queue!'; } catch (error) { console.log(error); message = error; statusCode = 500; } // 快速返回订单 ID return { statusCode, body: JSON.stringify({ message, orderId, }), }; }; Invoice Lambda Function 发票服务逻辑同样很简单,消费 SQS 指定队列中的消息,并将开具出的发票发送到客户订单信息的 email 中 module.exports.generate = (event, context, callback) => { console.log(event) try { for (const record of event.Records) { const messageAttributes = record.messageAttributes; console.log('OrderId is --> ', messageAttributes.orderId.stringValue); console.log('Message Body --> ', record.body); const reqBody = JSON.parse(record.body) // 睡眠 20 秒,模拟生成发票的耗时过程 setTimeout( () => { console.log("Receipt is generated and sent to :" + reqBody.email) }, 20000) } } catch (error) { console.log(error); } } 到此 demo 的代码就全部实现了,从中你可以看到: 我们没有关注 lambda 的底层服务细节,没有关注 sqs 的服务,只是简单的代码逻辑实现以及服务之间的串联定义 最后我们看一下整体的目录结构吧: . ├── app │ ├── invoice.js │ └── order.js ├── conf │ └── config.json ├── package.json └── serverless.yml 2 directories, 5 files 发布 Lambda 应用 在发布之前,编译一下应用,安装必须的 package「uuid 和 aws-sdk」 npm install 发布应用非常简单,只需要一条命令: sls deploy -v 运行上述命令后大概需要等带几十秒钟, 在构建的最后,会打印出我们的构建服务信息: 上图的 endpoints 就是我们一会要访问的 API gateway 触发 lambda 的入口,在调用之前,我们先到 AWS console 看一下我们定义的服务 lambda functions SQS-receverQueue API Gateway S3 从上图的构建信息中你应该还看到一个 S3 bucket 的名称,我们并没有创建 S3, 这是 SF 自动帮我们创建,用来存储 lambda zip package 的 测试 调用 API gateway 的 endpoint 来测试 lambda 打开 SQS 服务,你会发现,接收到一条消息: 接下来我们看看 Invoice Lambda function 的消费情况,打开 CloudWatch 查看 log: 从 log 中可以看出程序“耗费” 20 秒后打印了向客户邮件的 log(邮件也可以借助 AWS SES 邮件服务来实现) 至此,一个完整的 demo 就完成了,实际编写的代码并没有多少,就搞定了这么紧密的串联 删除服务 Lambda 是按照调用次数进行收取费用的,为了防止造成额外的开销,demo 结束后通常都会将服务销毁,使用 SF 销毁刚刚创建的服务也非常简单,只需要在 serverless.yml 文件目录执行这条命令: sls remove 总结与感受 AWS Lambda 是 Serverless 的典型,借助 Lambda 可以实现更小粒度的“服务”,无需服务搭建也加快了开发速度。Lambda 同样可以结合 AWS 很多其服务,接收请求,将计算结果传递给下游服务等。另外很多第三方合作伙伴也在加入 Lambda 的 trigger 大部队,给 Lambda 更多触发可能,同时,借助 CI/CD,可以快速实现功能闭环 开通 AWS free tier,足够你玩转 Lambda

优秀的个人博客,低调大师

SOA不是“万能钥匙” [SOA征文]

SOA技术在IT界掀起巨大的狂潮,然而它不同于以前的技术变革:模块化编程、面向对象、Web技术等,不论多难理解,总是能很快被大家接受,SOA之所以让很多人觉得难以理解,是因为它不再单纯地从IT人的角度理解IT系统,而是从业务人员的角度分析IT业务系统。 有两种现象相继呈现:一方面是企业SOA改造,精简企业业务流程,提升企业市场竞争与创新的能力,企业IT部门成为了企业管理的核心链条---“神经系统”;另一方面很多企业觉得无从下手,SOA太空无实,业务部门人员不愿支持,业务流程改造单靠IT部门是难以完成的,而企业内非IT部门,尤其是管理层对SOA了解的还很少… 一、 SOA是业务驱动的,不是技术驱动的 SOA概念的提出是在上个世纪了,但近两年在许多大公司相关产品与业绩推动下,SOA一下进入了实际应用的黄金阶段。 SOA的出发点是从业务角度重用应用系统的开发元素,最大程度地降低IT系统开发与维护的成本。很多企业的CIO都面临一个共同的问题:随着网络建设的浪潮涌过,各种业务系统的开发如雨后春笋,在大一些的企业,需要维护成百上千个业务系统是很常见的事,从机房配置、服务器管理、各种支撑系统的维护都让IT部门难以应付,更不用说病毒攻击过后的系统清理与业务恢复,仅仅是查看一下各个业务系统的状态,就需要工作人员花很长时间,要是业务的持续性保障,更是望尘莫及。业务系统的繁多与各自孤立,为新业务的上马带来更大困难,重复开发造成极大的浪费,信息不互通让每个系统都“麻雀虽小,五脏具全”,企业失去了市场竞争的灵活性,极大地触动了企业管理者的神经。 很多大公司开始推广ERP之类的大企业软件系统,希望在一个大系统架构中,可以融合更多的业务流程,各个业务的信息可以交流,避免各个“业务孤岛”带来的管理弊端与效率低下。然而随着单个系统的庞大,开发的难度指数般提升,要考虑的因素太多了,客户业务又千差万别,开发企业的管理成为极大瓶颈;另外“同制化”的设计模式恰恰抹杀了企业的创造力,而失去了“特点”的企业等于选择自杀。IT基础架构如何适应企业的“创造化”需求,新业务的开发如何快捷,如何降低IT支撑系统的管理成本,并提供持续性的服务保障,CIO们重新选择了SOA。 在这种情况下,SOA重新被提出来,按照时髦的解释,SOA是一种IT技术框架,是一种最佳实践,而不是一种具体的技术,能实现SOA的技术很多,如何选择的关键是达到SOA提出的业务灵活度的目标。 SOA的思路其实在IT人中有过类似的想法,我们回顾一下编程人员走过的历程:模块化编程就是把可重用的程序提炼出来,方便调用,提高软件的结构性;后来发展到面向对象,把数据与程序封装在一起,让软件设计人员的思路逐渐接近现实的人类思维方式;B/S架构的流行把客户端的变成维护简单化,业务更适合于网络方式;Web2.0的发展解决了B/S体系的交互问题;中间件技术让跨平台、跨语言的业务开发变得容易……IT人一直在探索、提炼可以重用的、优秀的软件模块,让我们的业务系统开发如搭积木一样容易。 虽然SOA是IT人员的思路,但推动SOA的是企业管理层,SOA是业务驱动发展,而不是技术驱动发展。新的视觉角度,并非所有的企业CIO们对SOA都得心应手,因为IT人员的业务认知弱点是由来已久的。 不再从IT开发人的眼光看待要开发的业务系统,而是从业务的使用者角度看待要开发的系统,面向服务就是面向系统的实际使用者,“谁干谁说的算”,系统应该具备什么功能,应该做成什么样子,要看用户使用的效果。简单地说,就是用“敏捷”的开发思路,代替了“闭门造车”的开发方式。所谓敏捷就是用户的参与,用户不懂你的专业“语言”,就需要快速的模型与界面展现,快速展现不重用是不现实的,而用户理解不从业务流程入手,是与用户没有共同语言的。 二、 SOA的“官方”解释 SOA的文章与资料很多,技术实现与最佳实践为多,这里只是说一下SOA的参考模型,展示SOA的架构。对于SOA的实现技术,会随着IT技术的发展更新,Web2.0是目前的一个最佳实践,SOA的目标的提高企业业务的灵活性,围绕这个目标,技术实现只是手段而已。 Sandy Carter给SOA的定义是:SOA(面向服务构架)是一种业务驱动的IT架构方式,支持对业务进行整合,使其成为一种相互联系、可重用的业务任务或服务。 SOA组成的五大要点: 1、 重用:创建服务与重用服务是SOA的工作。重用不仅可以节省费用,而且可以减少重复,建立企业间可以共享的服务,从而增加企业的灵活性,而且可以通过服务的实现、包装,利用已经证实是有效的核心应用和功能 2、 连通性:业务系统的连通,但松耦合方式,是实现企业业务灵活性的基础,获得连通性也是整合企业人员、信息、流程的前提 3、 流程:流程是企业对业务管理、监控的方式,SOA是实现对业务流程的支撑 4、 信息:信息是企业决策的基础,是企业的管理神经系统,掌握全面的信息、排除错误的信息、获得及时的信息是IT系统的基础功能 5、 协作:协作就是人员。创新不仅靠优秀的员工,更需要优秀的团队,在经济融合发展的今天,不仅依靠自己的团队,还要学会利用外部的力量,要协作就要互通与共享 企业服务总线ESB位于SOA架构的中心,是五大要素的“交通线”,更为重要的是它提供了新增“服务”的落脚点。有人说ESB是SOA的最大亮点,其实计算机技术里“总线”技术由来已久,总线的好处是方便功能的扩展,但总线本身的能力也限制了总线上应用的扩张,所以总线本身也需要不断地升级。ESB不仅是信息、命令的传输通道,而且是各服务交互的接口标准。 三、 SOA不是万能钥匙 SOA是业务驱动,说白了是管理驱动,虽然企业的IT化整合是IT发展的趋势,但每个企业的IT化发展都有自己的文化支撑,IT基础设施的建设、应用的开发是为了企业的业务服务的,脱离了这个宗旨,企业即使图一时的“新鲜”,也不可能长期陪着你玩。 推动企业SOA建设,是从企业的管理层面出发,管理层有“改变”的概念,才可以进行全面的分析与设计,而不是单靠IT技术部门就可以启动的,这一点是国内企业CIO面临的一个大难点。 这么说是基于两点:一是我们国内的IT发展历史还不长,IT部门的管理者在企业内的话语权还不够大,大部分CIO还没有进入企业的高级管理层,IT部门是企业业务的附加服务部门,还不能算是支撑部门;二是国内很多企业的IT建设是跨越式的,老外很羡慕我们新建设万兆网络、优良的处理中心,而很多老外还在使用10M的网络、COBOL设计的应用…我们能直接跨越落后技术是好事,但在IT管理能力与理解上就捉襟见肘,管理理念是需要实际体验的,没有实际的“磨合”,直接开始多业务的整合,用户找不到“感觉”。 SOA本身不是一套严格的技术理论,所谓“最佳实践”也是大家在理解过程中的“实地体验”,是从实际的管理工作与业务经营中总结出来的。而管理一定有其文化作为支撑,中国文化上的差异,可以很快接受一个新技术产品的引进,但对一个管理模式的引进却不尽然。二战后美国的管理体制直接输出到日本,但麦克阿瑟没有把日本变成美国第二,而在似与非似之间,出现了一个崭新的管理模式,日本经济的腾飞不能说不得益于这种模式;安全是“三分技术+七分管理”,这个道理在计算机安全界从一开始就在宣传,中国引进了防火墙、入侵检测、身份认证等多种产品技术、但BS7799、ITIL等安全管理与维护的“最佳实践”,却迟迟停留在培训上,国内真正采用的也是少之又少。 中国有句古话“取其精华、去其糟粕”,管理的思路源自于文化的底蕴,所以SOA这个从管理推动技术的“产品”,要落户中国企业,注定要在“融合”中国的管理意识之后,才会有大的作为。SOA不是万能钥匙,要开中国企业这把锁,需要做一定的改造,总结起来,需要解决下面几方面的问题: 1、 管理层重视:SOA是从上而下的业务管理整合,而国内大多企业对SOA的理解目前还处于IT管理层面,企业的管理者不理解就无法深入。让企业的高层领导重视IT,需要把IT部门从企业的服务部门转变为业务支撑部门。 2、 标准不是抹杀异化服务:重用服务是为了提高企业开发与管理的效率,越标准的“元件”,越可以降低成本;企业的生命不仅是降低相同服务的成本,还要能不断提供异化的业务,有区别才有市场上的竞争力。若在SOA推行中,过多地强调标准,忽略了创新,而降低了对新业务的支撑能力,同化了业务服务流程的开发,就成为SOA的大败笔。 3、 给国内开发商留下生存空间:SOA要求建立ESB,逐渐形成企业服务的标准化,这同时也对业务的开发商提出了要求,标准往往是大厂家主导的,其获得、授权、专利等后期技术壁垒是难预料的,毕竟TCP/IP那样完全公开的标准不容易,中国的业务开发商还都很弱小,若一味注重“国际”标准,势必提高市场进入的门槛,客观上也同化了产品的风格,没有了业务模式的“百花争鸣”,企业也丧失了市场竞争的优势。 4、 选择适合企业的:SOA是架构,需要实现技术支撑。中小企业的业务较少,其整合与升级不存在太大的难度,即使是大企业,在选择SOA支撑技术时,并非都要赶时髦,去选择最好的、最先进的,当然也往往是最昂贵的,完全可以根据用户的实际需求选择“最佳”的方式。经济发展的原则是:“永远选择最佳而不一定是最好的。” SOA是IT管理与发展的趋势,是业务的IT支撑构架,也代表了一种新技术方向,但如何为中国企业所用,需要中、西方的管理思路进一步融合,或者产生适合中国管理模式的SOA架构;SOA不是万能钥匙,解决管理问题离不开管理办法。 本文转自 zhaisj 51CTO博客,原文链接:http://blog.51cto.com/zhaisj/78915,如需转载请自行联系原作者

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册