怎样在aws developer 进行开发

1、AWS平台基于Java开发实现，系统的入口点为comactionsoftapplicationserverWFS类中的main方法。

2、在进行AWS平台二次开发时，需要引用平台已有的Jar包，他们是AWS安装目录下的bin\libs、bin\jdbc、bin\plugs三个文件夹下的Jar文件。

3、AWS平台启动时需要读取很多的配置文件，因此在配置开发环境时，需要为你的项目指定AWS的工作目录，该目录为AWS安装目录下的bin目录。

4、开发时应使用平台自带的JDK，安装位置在AWS安装目录下的JDK目录。

具体的搭建步骤如下：

1、创建一个Java项目

2、打开项目属性页面，选择Java Build Path配置页，并将JRE设置为AWS平台自带的JDK下的JRE

3、通过ADD External JARS命令将AWS平台所需的Jar包加入到项目中。

4、选中项目，点击右键，选择Debug As菜单中的DebugConfigurations菜单。

5、在打开的Debug Configuration窗口中，创建一个Java Application的调试项目，输入调试项目的Name，并在Main Class中指定comactionsoftapplicationserverWFS类。也可以通过点击Search按钮，让系统帮你搜索到WFS类

6、 在上图中点击Arguments页签，设置Working directory配置项，选择Other，并通过File System按钮选择你的AWS安装目录下的bin目录作为项目的工作路径

如果一切顺利的话，现在就可以像开发一般的Java程序一样了。

云平台不知道题主说的是哪种？一般云计算平台分为常见的一下类型：

IaaS云说的是基础设施即服务，这种云计算平台提供的是IT领域的基础计算资源，比如:计算、内存，存储、网络等。这种云平台一般底层通过虚拟化（kvm,xen,exsi）技术做底层资源的抽象整合，然后通过虚拟机的形式提供给用户一个完整的操作系统环境。典型的产品有：开源的OpenStack、CloudStack。商业的Vmware公司的vsphere等。公有云产品就很多了:阿里云，腾讯云，百度云，ucloud，青云，滴滴云，AWS等。

2PaaS云说的是平台即服务，这种云计算平台与IaaS平台最大的差别在于，IaaS云只是提供了基础的计算存储网络等资源，应用运行的环境需要专门的应用运维工程师去部署和运维环境，而PaaS云不仅提供了计算等基础资源外，还提供了runtime以及中间件服务。最直观的体验就是早期的京东JAE服务，用法很简单，只需要上传一个PHP源码压缩包，应用就可以直接运行了。简单的来说PaaS云让用户只关注业务不需要关注资源和runtime以及中间件的一种云平台。典型的产品：pivotalcloudfoundray，IBMbluemix,VMwarePKS。

3SaaS云说的是软件即服务，相对于前两种云比较来看个人感觉最大的区别在于，SaaS服务直接面向普通用户的，IaaS云面向运维工程师降低运维工程师管理硬件基础设施提高运维的效率，PaaS云面向开发者快速提供开发环境以及部署环境等，这两种云都不是直接面向普通用户的，都是面向IT人员。这种一般来说比较典型产品就是saleforce，石墨文档等。

以上是三种云计算的典型分类方法。

但是随着近些年来的容器技术的发展，也衍生出来更多细化的分类：

比如：CaaS云，容器即服务。FaaS函数即服务等等。

对于这三种云平台来说部署的方式各不相同，技术难度也不一样。需要明确自己的使用场景，然后确定自己使用的类型。

对于搭建云平台技术。现在一般推荐使用docker+k8s的方式去构建一个miniPaaS平台。本人从事云计算运维开发多年，以上是我的回答。

防火墙没有给对应端口开放。亚马逊AWS是亚马逊提供的是全球最全面、应用最广泛的云平台，从全球数据中心提供超过200项功能齐全的服务，有对应的防火墙阻挡，在防火墙没有给对应端口开放时，就无法再次使用AWS平台，里面功能也无法正常使用。

我想单独开一个叫《Serverless往事》的topic，讲述从2018年年初开始我们“艰难探索”新架构的一些故事。Topic会不定期更新，希望能一直更新到一个大型网站的面世。

18年初，突然得到领导通知，要起一个serverless的web应用。当时并不清楚具体缘由，只是隐约听说原先架构成本过高已无力支撑产品上线。一番调研后，海外的某个组首次实践了serverless并获得巨大成功。大中华区CEO很快通知我们，要在中国推广aws serverless。

当时的情况极为尴尬：除了一些朴素的java知识，全组甚至全厂都没有粗通架构的后端；前端也极为原始，几乎没人接触过三大框架；CI/CD，更是无从谈起。最大的困难是：我厂只做B端，对Internet网络攻击毫无抵抗力。然后，我们接到了任务：搭建一个叫E-pub的互联网web应用。一个新时代就这样开始了。。。

E-pub是我所在某招聘相关产品组的一个子模块，主要面向互联网端的应聘者。业务流很简单：应聘者通过E-pub录入个人信息，并向雇主申请Job。雇主在企业内部HR系（姑且叫 IVF 吧）能及时同步应聘者申请。主要页面其实就两个：1 隐私条款 2 用户信息录入页面

业务确定后我们立马讨论了技术栈的选择。

两个礼拜后，我旁听了组里领导和arc team的Review，依稀记得对方来了两日本人和一个印度人。不得不佩服我领导，他和对方leaders谈笑风生，独留我一人茫然无知，大概是我听力实在是太差了吧。两次review会议后，E-pub得出了大体如下的框架。

架构很直白，服务部署在lambda上，应聘者只能通过api gateway读取Job信息，并录入个人信息；IVF（对的，是我们的那个内部HR系统）轮询E-pub，同步信息后删除Dynamodb和S3里的记录。

回过头来看，这个设计甚至不如一个学生管理系统复杂，不过在E-pub场景里却是一个很务实的选择。

说点闲话，汉语语境里 保守 和 激进 都带明显的贬义性质。很多人喜欢评论别人的技术选型太保守或是太激进，然后沾沾自喜一番。但是评价者自身没有技术判断力呢？架构的选择也是如此，其实并没有保守或是激进之说，简单务实才是最正确的选择。

到此为止我们的E-pub正式进入开发阶段，虽然系统简单但是五脏俱全。之后我们仅仅用了一个多月就搭起了这个web应用，对比IVF年复一年的跳票，不得不说serverless带给了我们巨大的惊喜。总结起来大约有这么几点优势：

不久之后，我们迅速开启了另一个新项目——M-pub。这次挑战更胜从前，更复杂的web安全、DB读写限制、MT、微服务治理、CI/CD……世上并没有一劳永逸的框架，更没有放之四海皆准的技术。我们又该如何抉择， to be continue

有一次我向某日本领导请教技术栈的问题，她道出了一些很有趣的事。领导们并不关心技术，更不关心开发体验，他们只想要一个低成本的产品。这些话让我茅塞顿开：对于底层小职员来说，我们追求新技术是因为技术是安身立命的本钱；但领导们不是，他们讲的是管理，要的是可控。从某种意义上来说，正确理解领导的意图其实也是我们底层小职员安身立命的技能。