40岁还能编程吗？

美国工人的平均年龄是42岁，而StackOverflow的调查显示程序员中只有约13%的人超过40岁，那更多的人都去哪了呢？是转行了还是晋升管理岗了呢？在40岁之后继续从事软件开发真的行不通吗？

ROBFLETCHER,NETFLIX(LOSGATOS,CA)高级软件工程师，45岁

我从事编程工作近16年了，之前有几年是独立开发者，在42岁时加入了Netflix任高级软件工程师。

我几乎每天都写代码，目前最喜欢的语言是Kotlin，正在学的语言是Go，平时主要用Java,Scala和Groovy。大部分时间都用来了学习新知识，并且也知道自己不会是一个好的管理者。:p

很多事都取决于你的态度，不要成为那个瞧不起任何新技术的老人。利用你的经验，就未来的技术选择做出明智的决定。虽然，技术日新月异，但我们的经验依旧有用武之地。

EBBEKRISTENSEN,丹麦PREVASA/S高级软件架构师，62岁

从1980年我获得BSEE（电机工程学士学位）并得到我的第一份工作以来，我一直都在编程。在大多数的日子里，我都在写代码，并没有管理任务。事实上，我也认为在管理岗位上，我不会像现在这样出色。

我58岁时获得了现在的工作。在公司里，只有两个同事比我年纪大，但我不觉得这有什么问题。因为，编程就是我一直喜欢做，也是我最擅长做的。

我的经验就是，不断寻找学习的机会，并随时准备抓住机会。

VICTORVOLKMAN,ProQuest高级软件工程师，54岁

几乎每隔两年，就会诞生一个人们称之为颠覆性的平台或技术。不要觉得痛苦，花3,4天时间了解了解新的技术，然后继续工作。30多年来，我也不得不每四年就重新学习几乎所有的东西。之前，我工作于一个六人的团队，大家都是48到56岁，几乎任何专业领域的问题我们都能一起讨论。

这就是我的职业生涯：

在MS-DOS中写C和Assembly

学习用C++和MFC写Windows程序

学习在Unix里进行CGI-Binweb开发

学习C#

学习Java和JSP

学习移动开发：iOS/Android/Blackberry

回到Unix，开始开发Python

AWS(EC2,RDS,SQS...)

我能给的建议就是，如果哪天你对编程没了兴趣，就离开吧，去管理岗或者干点别的什么。但如果还是喜欢编程，那就不断学习，继续下去。

关于微服务架构的文章相信大家应该看过不少了，其中关于微服务的架构技巧以及开发工具的介绍也有很多。

今天，海南电脑培训http://www.kmbdqn.cn/就给大家汇总了一下，其中适合微服务架构的工具都有哪些种类，一起来了解一下吧。

API管理和测试1.APIFortressAPIFortress是API测试和健康检测工具，为企业级API提供自动化的功能测试、健康检测和负载测试。

它的设计原则是无代码，完全基于现代API架构实践和模式而构建。

2.PostmanPostman是面向个体开发者和团队的API开发套件，可让你轻松运行UI驱动的API测试。

Postman还是一个功能强大的HTTP客户端，让RESTfulAPI探索变得轻而易举。

用户可以将简单和复杂的HTTP请求组合在一起，实现快速的API测试、开发和文档化。

3.TykTyk是一款开箱即用的开源API管理平台，速度快，可伸缩。

无论是部署在内部，还是部署在云端，或者使用两者的混合，对Tyk来说都不在话下。

除了可以降低管理成本，Tyk还将为你带来高可用性和低延迟。

消息服务4.RabbitMQRabbitMQ可作为微服务之间的通信桥梁，它支持各种模式，可提高应用程序的可伸缩性，并解决大多数分布式系统都存在的问题。

RabbitMQ可用在微服务环境或任何其他分布式系统中。

你还可以使用这个工具在服务之间交换事件。

5.亚马逊简单队列服务(SQS)亚马逊SQS提供了强大、灵活且可靠的微服务通信机制。

作为一种基于发布订阅的微服务通信模型，亚马逊SQS可以帮助开发人员解决很多问题。

除了更好的安全性之外，队列还通过为待处理消息提供储存来增强可靠性。

6.ApacheKafka消息队列对于微服务架构来说是非常重要的，可用来处理微服务之间的通信以及微服务与外部源之间的通信，不管是密集型的数据处理还是API调用。

ApacheKafka是一个具有高容错和d性的分布式流处理平台。

关于API的开发设计相信大多数的程序员应该都掌握了不少方法了，今天我们就通过案例分析来简单了解一下，关于API设计都有哪些常见的问题。

当我们谈论到“REST”，可以讲的通俗一点它就是一种基于HTTP形式的API。事实上，大量含有URI的“REST”形式的API都有提供CRUD *** 作，有些URI是在负载的时候就嵌入的，所以可以说RESTful是一开始就有的。但是现在我偶尔还会听到“CRUDL”这个名词，这个“L”代表List。

当我在AWS工作时，我们常做的事是设计一个服务或者一款APP的数据层和它的控制层。举例，假定数据库像RDS服务一样。那么在app的控制层中你去创建，配置，备份，启动，停止和删除数据库。数据层主要内容是SQL语句，连接池和RDBMS包

非常有趣的是我们需要去注意的一点是控制层可以非常好的匹配RESTFUl风格的API，但是数据层就不是这样了。在数据库当中REST并非属于必要，(但是DynamoDB数据库的数据层是非常嵌合RESTFUL)。

我在想模式能否是这样，当你在控制层去删除和创建对象时，控制层可以很好嵌合大多数RESTFUL风格的API。数据层却完全不一样。要不是因为REST和控制层像是天造地设一样合适，我还以为不论什么想要替换掉REST都将从数据层开始。

REST-ful缺陷我们想超越REST的原因可能有哪些?下面我列出了一些：

延迟

创建和销毁一个HTTP连接的每一个 *** 作都不是没有代价的。虽然为了减小这种代价努力了几十年，但是它依然存在。

比如说两个我身边的朋友创建的消息服务的例子：AmazonSQS和MQ.SQS已经运行了十多年，每秒处理百万级的消息，而且如果你的消息发送者和接收者能合理平衡的话，可以做到出奇的快。甚至我听说过消息还没有发送就已经被接受的例子。其实是长轮询的接收者在发送端销毁PutMessage的HTTP连接之前就已经收到消息。沙河电脑培训认为一方面，它没有使用HTTP，而是用了TCP/IP长连接和它自己的报文协议。所以可以得到惊讶的发送和接收延迟。但是另一方面，你的消息吞吐量受限于关闭这些连接的“messagebroker”所能处理的连接数。很多选择MQ的人的原因相信他们这么做的因为是不想用RESTful接口。

---