读《凤凰架构》感悟

本书提供了一个完整的网站代码，网站名字是：凤凰书店。该网站是一个网上卖书的站点。类似于互联网最早期的亚马逊书城、当当网。一个传统的互联网网站。

值得关注的是该书提供的不仅仅是勉强把这个网站实现出来的代码，而是用非常好的标准和风格实现了，并且实现了5套，让读者观察5套网站代码的区别，去深刻体会网站后台架构的演进。（很多已有的互联网网站其实是勉强实现出来的，后台代码已经腐坏了，由公司的救火英雄们心力交瘁的维护着），如果能把这5套代码摸透，那也许你能带领公司构建一个简洁且稳定的网站，从容的工作而不做救火英雄。

5套代码是用java实现的，这是因为过去10年的网站后台还是以java代码为主。但5套代码分别是互联网不同发展时期的产物，正如书中所说，架构不是一成不变的，而是不断演变的。5套代码各有特点，在不同的时期，公司会选择不同的架构，来满足业务需求。

凤凰书店的功能在现在看来并不复杂，标准的用户注册登录、浏览书籍和购买。第1套代码中，使用java Spring Boot就实现了，只需要一个java进程，也许互联网早期的公司就是这么实现的，足以证明这个网站功能简单。但随着互联网的发展，在单个进程上存在性能和功能扩展问题。于是有了后面的实现架构。

第2套代码中，使用了java Spring Cloud实现，该实现把单进程里面的认证授权、用户账号、商铺信息、交易服务拆分成不同的服务进程，部署到多个服务器上，解决了单服务器性能扩展的问题，但引入了分布式架构的复杂度（配置中心、服务发现、服务治理、负载均衡、HTTP协议），运维难度急剧加大。好在还全是java实现的，公司的java程序员还能搞得定，这也算是java版的微服务架构了。

2017年Kubernetes赢得统治地位，Kubernetes以pod的方式讲所有服务进程分发到不同的机器上运行，极大的降低了运维人力，并提供了异构能力，不再需要全部都是java实现，一些中间件可以以pod方式部署其他语言的服务进程。第3套代码则采用了Kubernetes的实现，当然每套实现业务代码基本都一样，不一样的是代码组织和运维的方式。尽管降低了运维成本，但Kubernetes缺乏一些java Spring Cloud的能力，例如认证授权。在使用Kubernetes实现时，Kubernetes没有的功能也需要把原有的java Spring Cloud功能搬迁过来到pod中运行。

随后k8s引入了Istio，解决了Kubernetes的欠缺，把基础设施全部移到业务代码之外。第4套代码则采用Istio的方式部署，几乎彻底移除了java Spring Cloud实现中的基础设施部分，只保留了业务代码，就可以部署到Istio环境，享受Istio提供的基础设施。

最后提供了第5套代码，无服务框架，准确的说作者没有提供代码，因为是无服务。书中给出的示例是云计算老大AWS的lambda。所谓无服务，其实是AWS已经帮我们把Kubernetes和Istio部署在云端了，包括redis、mysql这些常用基础组件，在AWS上也能直接使用，相当于把运维能力外包给AWS，从而省却了运维成本，专注业务开发，即使是一个开发人员也能独自开个公司做个稳定的网站了，只需按流量给AWS付费即可。

总结一下互联网行业，如果是做个信息网站，现在成本非常低，租用AWS就可以获得最优秀的基础设施运维能力，数据持久化、高速缓存、串行互斥、发短信等一系列基础功能都可以直接获得，自己只需要实现业务代码即可，而业务代码又被AWS的lambda抽象成一个个无状态函数，或者说一个个http接口。我们只需要为自己的业务编写这部分代码，就可以完成一个网站，要是担心前端没有流量，还能接入微信小程序、公众号这样的终端。研发成本低到一个人也能完成，就像抖音短视频，30年前要做内容影视，需要一个很大的团队携带庞大的资金才能完成，现如今一个人就可以是一个团队，拍出很多内容影视。

正如书中所说，整个团队只需要少数两三个人熟悉全貌，剩下的大部分人只需要使用最简单的方式开发业务逻辑，这个团队就可以运作的很好，而AWS云厂商，则充当了团队中掌握全貌的人。当然，如果不是纯粹的互联网业务，涉及到一些自己的硬件，不同于互联网C/S架构的系统构建，无法使用AWS云服务的部分，才需要其他定制的设计和实现。