Intro
本文没有任何技术成分，多为 🤔 与吹逼。
很幸运，我在 2011 年的时候就开始接触 AWS，租过服务器、写过客户端等等，也是第一次在国内这种环境下接触到了云的存在。如果用一个词来描述我的感官的话，那就是弹性。一个只有周期繁忙的系统，比如说学校的选课系统，并不需要一台强悍的小型机，只需要在定期租用较大的实例就可以支持大并发的应用，在 peak 过后，再继续租用廉价的服务器，这就是弹性最开始的意思。
随着时间的流逝，按需使用（on provisioning）可以被认为是云平台最重要的功能了，在我参与的一些海外项目中，已经没有人能告诉我到底有多少台服务器在运行，所有的一切都是不断变化的，是响应负载的，我也一直认为这是云平台最大的意义，也就是省钱。
按需使用是一部分，还有就是托管所带来的成本降低。几年前还有人在企业内部署了 Windows AD 、CRM、Exchange 等，并且雇了几个脚本高手做维护，而现在，使用 SaaS 的代价只有不到 10%。对于工程师，我们写代码时，我们真正的价值是实现业务，运行代码的服务器和数据库很重要，但是只是支撑我们的业务，而不是为我们带来收益，所以，云可以把这一部分工作接走，让我们的人专注于写代码，总结来说就是让擅长的人做擅长的事情。
响应变化是搞软件最根本的目标，又快又稳的更新产品是我们最想做的事情，所以有了持续集成、持续交付等方法论，有了很强悍的 CI 工具来帮我们编译、打包、部署。为了更好的响应变化，我们要做解耦，就像最开始学习 OOP 一样，分开变化。每个分开的部分，来自己适应或者管理自己的资源。现在一台服务器已经非常便宜了，SSD 的 AWS RDS，32G 内存一年的租用费用也就 3000$ 左右，还不如一个实习生半个月的工资。以前我们认为很金贵的东西，突然一下变的非常廉价，而这写廉价的资源，使得我们可以用更松耦合的方式来组织应用架构，也就是微服务——我们可以给每个服务配上依赖的资源，让每个服务来自己决定需要什么资源。
回到国内
今年参与了很多国内的项目，也见识到了国内行业的兴盛。特别是在传统行业，地产、美容、航空等都有很强的技术团队在尝试的往云上走。有一个笑话就是：现在创业公司 95% 以上都是云字作为结尾的。但是遗憾的是，除了 BAT 这种一线互联网公司能真正的做到 Cloud Native，大多数的中小规模的或者传统行业的对云的使用，还是停留在租用虚拟机的状态下，而且也很难一时半会的走向我们对云的愿景。我常常说，我们只组了一个机房，如果是公有云，那就是别人替我们维护，如果是自私云，那就是我们自己在维护。
与很多身经百战的前辈讨论，大家的想法都是类似的：我何尝不想做到真正云，我想让早上通过评审的代码在 merge 后，15 分钟就能让用户看到修改；我想白天跑应用，晚上跑大数据，每个子系统都是按照自己的负载来调整资源；我也不想要 1000+ 张表的数据库，也不想要一个巨无霸的 redis；我想有一个 dashboard 能告诉我，我的系统现在是个什么情况；我要一条命令就能出来报表、日志；我不想招那种顶尖的、不出错的、有大心脏的运维，我只想要更多的人去实现业务。
即时这些前辈所服务的公司有让人羡慕的现金流，和各种精通奇技淫巧的大神，但是面对现状还是缺乏改变的勇气，一方面是已有成功不允许有巨大风险的改变，另一方面不是技术的缺失，而是没有足够方案设计能力。
Kubernets 是一个很好的平台，它让大家对稍微改造一下自己的云产生了兴趣，一线互联网公司已经在 k8s 上制作自己的服务治理平台，这是一个非常好的趋势（我们在制作服务治理工具时，哪里有这么强悍的家具啊！），而这些企业内部的朋友，已经享受到了早上写完代码，下午跑性能测试，做 code review，然后 QA 再直接上线了，他们已经摆脱了 delivery train 的梦魇，当有新的需求来到时，不会是垂头丧气眉头紧锁，而是使用 MVP 的做法立刻开始制作 prototype 了，两天后就能有一个 showcase。
回想起我用 flood.io 去给服务做性能测试时，我可以两行命令创建出云环境与其依赖，然后测试的 case 都是 DSL 编写，最后的运行也是直接在云上的 Grid 做请求，基本上就是吹着口哨看结果——APM、Log Center 可以给我很好的反馈，并且我还可以自己埋点来查看系统的弱点。我的大部分精力是放在了 case 的设计上，而不用担心我的环境是否和生产环境对等，难到生活不应该是这样的吗？
阻碍我们云化的东西
传统的思维跟不上摩尔定律的改变。我曾经问过一个很白痴的问题：为啥我们要和国内的公有云签合同，说好多少钱？难道不是用多少给多少吗？然后我立刻被羞辱，前辈像看傻逼一样的看我，答曰：你没听过预算这个词吗？我瞬间就明白问题在哪里了，很多朋友的国内小项目就是这样，甩给你三台机器，然后问你要产品，钱也是合同上规定的。既然这一点限定了我们，那自然不需要过多的考虑弹性了，因为预算限定了你的资源。
再根本上一点也许是东亚人做事的风格，我们在骨子里是不信任任何人的，并且有极强的控制欲。一个 Team Lead 对技术栈的偏好可以确定大家用什么框架（也就是为什么全国都是阿里 dobbo ）。我们不相信给你一个无限制的云平台账号你不会用来谋私利，我们担心你丫乱开昂贵的数据库。boss 总是要结果，而不在乎过程，所以段子一样的场景每天都在上演——你要捡烟头，那我就能给你捡一河滩。
曾经问过几位资深的咨询师，如果我要推微服务，我应该从哪里推？印象最深的回答是，如果你能改变客户的组织结构，那就先改组织吧。我摸摸我胸口的二两肉，咽了口唾沫。回到国内的场景，也许是不是要思考一下搞中国特色的微服务实践了？或者，一个应用级别的架构实践，有必要到这个层级吗？
如今大部分软件都非常像埃及金字塔，由成千上万的石块一个摞一个构成，没有结构上的集成，是由暴力和成千上万的奴隶完成的。
这句我很喜欢的话也阐述了很多软件的问题，我见过很多巨无霸级别的 Spring MVC 或者 ESB 应用，甚至我都怀疑这东西怎么能运行，里面没有设计，只有堆砌，而这些东西还不敢乱动——因为即使它再差劲，也在运行。就像金字塔一样整齐的石块，但是成千上万的奴隶只为了法老而工作，而我们真正想要的是一座欣欣向荣的城市。微服务和城市有很好的对应关系，城市有标准的道路、水电网络、土地使用规则等等，至于每个企业、单位怎么使用，这不是由城市限定的，大量的小区周围会出现购物广场，而购物广场的规模也是由小区的规模所决定。
所以很多人问我，如何拆分微服务，或者我该怎么开始微服务，往往非常难以回答。一个独立的、自治的服务需要很多东西：注册发现、资源依赖、负载均衡、横向扩展、日志、SSL 等等，这些东西不是一个 MVC 就可以解决的，也就是说你总得有一个差不多有水电的平台，而这个平台的建设成本已经远远大于从业务领域拆出一个服务了。往往这一点，是最终让一线的工程师望而却步的理由，我们很难直接开始，更不用提将 MVC 拆成前后端分离的架构或者实现反应式框架了。
好的方面
往好的方面想，容器化给我们带来了一次小的革命，大家都在用 docker，不管 docker 里的跑的代码架构是多么陈旧，总之，每个人都意识到这是一个好用的箱子。docker 的火热带来了容器级别的编排，而容器级别的编排也就意味着服务的治理，从趋势上来看，至少技术是绝对在向这个方向发展的。今年我最喜欢的东西就是 Service Mesh，而 Service Mesh 也许是制作一个“平台”最好的方法论了。Conduit 也许是一个不错的产品，也很期待身边有没有第一个吃螃蟹的人。
网友评论