春节特别放送（上）_ 有的放矢，事半功倍 你好，我是周老师的课程编辑王惠。今天是正月初一，首先在这里祝你春节快乐、牛年吉祥，在新的一年，学业进步、工作顺利~另外疫情当前，你也要注意保护好身体。

不知你还记不记得在开篇词里，我们曾发起过一个活动： 在课程更新的过程中，分享出你的学习心得、实践感悟等等，或者也可以分享出你自己在架构设计中的实践经历、遇到的坑以及避坑的经验。在期中和期末时，课程编辑会甄选出优秀的留言分享内容，专门做一个展示模块，最后还会送出这门课程的纸质版图书。

那么到了这里，我们就已经跟随老师走完一半的学习之旅了，相信这两个半月的时间里，你学到了很多，究竟掌握得怎么样呢？

所以在春节假期这段时间，正好我们可以把那些硬核艰深的架构知识放一放，轻松一下，一起来复盘复盘我们学过的知识点，做到有的放矢地学习。

然后，我们再通过同学们的优秀留言，来理解那些自己可能还不够熟悉的课程内容，或者体验一下自己没有经历过的实践过程、没有亲身踩过的坑，希望以此能帮助你更高效地学习课程。

好，我们开始吧。

“演进中的架构”模块内容复盘

这个模块里，我们一起了解了微服务发展历程中出现的大量技术名词、概念，以及了解了这些技术的时代背景和探索过程，同时也在此过程中，更深入地理解了Unix设计哲学的思想。

  • 原始分布式时代。这是计算机科学对分布式和服务化的第一次探索，DCE、CORBA等都是早期的分布式基础架构，原始分布式架构设计的主要目的，就是为了追求简单、符合 Unix 哲学的分布式系统，这也是软件开发者对分布式系统最初的美好愿景。
  • 单体系统时代。单体作为迄今为止使用人数最多的一种软件架构风格，具有易于分层、易于开发、易于部署测试、进程内的高效交互等优势。它也存在一些关键性的问题，比如存在隔离与自治能力上的欠缺、不兼容“Phoenix”的特性等。但这并不意味着单体最终会被微服务所取代，未来它仍然会长期存在。
  • SOA时代。虽然SOA架构具有完善的理论和工具，可以解决分布式系统中几乎所有主要的技术问题，曾经也被视为更大规模的软件发展的方向，但它最终还是没能成为一种普适的软件架构。为什么呢？实际上这正是由于SOA架构过于严谨精密的流程与理论，使得它脱离了人民群众，从而走上了被架构者抛弃的不归路。
  • 微服务时代。早期的微服务架构作为SOA的一种轻量化的补救方案，是在SOA发展的同时被催生出来的产物。但发展到现在，可以说微服务已然成为了一种独立的架构风格。在该架构模式下，我们需要解决什么问题，就引入什么工具；团队熟悉什么技术，就使用什么框架，对开发者来说十分友善。不过我们也同样需要警惕，因为在微服务中，对于那些分布式服务的问题不再有统一的解决方案，因此可以说微服务所带来的自由是一把双刃剑。
  • 后微服务时代。现在人们常说的“云原生”时代，就是课程中所讲的后微服务时代，因为它跟前面的微服务时代中追求的目标相比，并没有什么本质的改变，都是通过一系列小型服务去构建大型系统。可以说，容器化技术、虚拟化技术的发展和兴起，对软件架构、软件开发产生了很大改变，软件和硬件的界限开始变得模糊，业务与技术能够完全分离，远程与本地完全透明，如同老师所说，也许这就是分布式架构最好的时代。
  • 无服务时代。无服务是近几年出现的新概念，它最大的卖点就是简单，只涉及了后端设施和函数两块内容，其设计目标是为了让开发者能够更纯粹地关注业务。不过我们要注意，与单体架构、微服务架构不同，无服务架构天生的一些特点，比如冷启动、无状态、运行时间有限制等等，决定了它不是一种具有普适性的架构模式，我们也不要误会它比微服务更先进。

模块留言精选

第1讲

来自@Jxin

我认为，可以从两个方面来看待“简单”，分别是业务和技术。

先说业务。现代软件系统的业务复杂性越来越高，而分离关注点，无疑是应对日益增长的业务复杂性的有效手段。但如果依旧是一个大型单体系统（所有业务单元都在一个容器下），那么跨业务单元的知识诉求便很难避免了，并且在开发迭代以及版本发布中，彼此还会相互影响。而微服务的出现，就为其提供了设定物理边界的技术基础，这就使得多个特性团队对业务知识的诉求可以收敛在自身领域内，降低了单个特性团队所需了解的业务知识。

再来说下技术。这里我认为主要体现在技术隔离上。就如同RPC可以让你像调用本地方法一样调用远程方法，微服务技术组件的出现，大多是为了让开发人员可以基于意图，去使用各种协调分布式系统的工具，而不用深入具体工具的实现细节，去研究怎么解决的分布式难题。

另外，就像SpringBoot提到的生产就绪，微服务的生态已经不局限于开发的阶段。在部署和运行阶段都有健全组件的支持。它可以让开发人员基于意图就可以简便地实现金丝雀发布，基于意图就能拿到所有系统运行期的数据。而所有的这些便利，都算是技术隔离带来的好处。

来自@J.Spring

目前我们团队在做从传统HTTP直接调用、向SOA服务化架构的改造，这个过程让我对SpringCloud这种面向HTTP的服务，以及Dubbo-RPC服务产生了疑问。

因为单论简单，SpringCloud看起来更简单，但它缺乏完善且强大的服务治理能力。而Dubbo框架看似沉重，却拥有很强大的服务治理功能。

所以我认为，简单的东西可能后期会变得复杂。而一开始的复杂，可能后期会变得简单。

第2讲

来自@STOREFEE

如果可以很明显地预估到项目的开发规模不会很大，但是对性能要求很高，局部范围需要经常迭代，而且需要多点部署的场景，那就非常适合单体架构。

不过我观察到，凡是和互联网沾边的流行的软件项目，基本其规模都在不断膨胀，趋向于包罗万象。因为现在很多用户会觉得软件越来越多，去切换不同的东西太麻烦了，有的还得申请账号、填写资料等，比较繁琐。最明显的例子就是石墨和飞书，前几年感觉石墨文档很贴近Word，挺不错的。另外，现在飞书、企业微信等工具，都整合了企业聊天、会议、文档、存储、绘图等一系列的东西。

所以说像这种一站式服务，绝对会采用非单体架构。

来自@小高

单体架构并不是一无是处的。在公司的初始阶段，为了让业务快速上线，就必须得采用单体架构。然后随着业务的增长，架构才得以演进。

还是那句话，架构不是一成不变的，而是持续演进的。或许，微服务也不是终点。

第3讲

来自@Wacky小恺

在目前的信息技术行业中，如果按照严谨的SOA架构去设计系统，那么不仅为开发人员带来了负担，也加重了用户的学习成本，使得在快速迭代中，需求会被架构所限制。

我认为软件的设计应当为简洁的、无门槛使用的，比如国民产品微信，不需要过多的学习成本即可使用。而SOA的风格是自上向下的工业标准，自然不符合时代的潮流，“不接地气”，因而就会被时代所抛弃。

来自@Frank

我之前也使用过SOAP协议来开发服务，那时候，我们公司自己搞了一个ESB，但是好景不长。一开始是所有服务调用均走ESB，不过后来由于某些原因，直接绕过了ESB，当时我其实并不理解为什么要这么做。后面随着不断学习才慢慢明白，之前搞得ESB，服务之间的协议等等的 “太重”了，实施维护成本很高，不适合自身业务的发展。

第4讲

来自@陈珙

我做.Net实施微服务的时候，当时业界还没有特别成熟的选型与方案，所以自己在组件、方案之间选型对比、整合花了不少的功夫。

老师说架构师是做平衡与取舍，而开发工程师是实施。我也这么认为。微服务的分而治之、化繁为简的思想是减少了业务开发复杂度，但同时引入了很多组件支撑服务，因此加大了技术复杂度。

我自己是有几条设计原则的，如下：

  • 技术服务于架构，架构服务于业务；
  • 康威定律；
  • 架构的实施是需要对应开发模式支撑的。

那总结起来就是，业务规模与团队规模决定了架构的规模，一个增删查改的系统并不需要用微服务架构；使用了前后端分离，那么团队里多数是有前端工程师；由微服务架构拆分引起的量变导致质变，结合DevOps能更好地支持运作。

来自@Mr.Chen

其实用不用微服务架构，主要取决于业务，撇开业务谈架构都是在耍流氓！

我们公司面向企业私有化的项目就没有用微服务，主要是用户的并发量小，考虑到部署和运维的简单，直接上单体架构。

第5讲

来自@zhanyd

软件架构的发展方向，是慢慢地把与业务无关的技术问题，从软件的层面剥离出来，在硬件的基础设施之内就被悄悄解决掉，让开发人员只专注于业务，真正“围绕业务能力构建”团队与产品。

把复杂的问题交给计算机硬件解决，使得开发人员只需要关注业务，让开发越来越简单，同时能够调用的计算机资源也会越来越强大。

这也符合奥卡姆剃刀原则：“如无必要，勿增实体”。如果问题能让计算机自动解决，就不要麻烦人类。

来自@Jxin

分布式架构发展到服务网格后，真的是到达“最好的时代”了吗？我的回答是：没有最好，只有更好。

云原生下，SLS的FaaS和服务网格的纯应用包，这两个各自的需求差异还是挺大的。前者算是技术架构上对效率和成本的创新，后者算是业务架构上对技术分离的追求。这是两个发展分支，但是也不知道会不会产生新的问题。

不过，业务知识的易传递性、代码的开发、软件发布的效率、高可用和高性能的诉求，等等，这些在可见的未来，应该还会是需要持续解决的问题。

第6讲

来自@大D

2011年我刚毕业进公司，开始使用Mule、ESB做集成，当时我也是初次接触WebService这一套东西，SOAP、WSDL等等用了一年也没搞明白都是干啥用的，感觉就是俩字“复杂”。再后来，公司的产品采用OSGI的方式，自己通过订制Eclipse插件的方式开发了一套IDE，每次打包要勾选一堆的依赖，解决依赖冲突、查找依赖，苦不堪言。这些东西本身就有很多技术壁垒和学习成本。

再后来，Maven流行，开始各种分模块，后面公司用MQ实现了一套总线，现在看来它就类似于老师讲的事件驱动架构，这个架构还是要自己解决很多负载、补偿、事务等问题，不过总体来说比之前有进步。

然后直到微服务的出现，感觉轻松了很多，框架层面的东西已经有了很多的解决方案，选择一个合适的就行，其他的专注于业务开发即可。

现在的年轻人确实赶上了一个好时代，不用理解那么多的复杂实现，可以更多地磨练自身编码能力。但我觉得经历过的都是财富，不然也不会对老师的课程产生强烈的共鸣。

来自@walkingonair

我正在腾讯云上摸索无服务的架构模式，完全赞同老师的说法。选择无服务的初始原因是由于微信小程序生态的强大，在腾讯云上进行产品的开发，能大大降低人力成本、运维成本，提高产品的开发速度，帮助创业小公司度过艰难的初期。

同时，无服务的架构模式，也能在业务量快速上升时，只需要简单增加成本投入，即可快速提高整个架构的业务承载能力，满足未来更大的业务增长。

但这种架构模式的不足也是十分明显的：

  • 我虽然是一个全栈开发工程师，但是平常使用最多的还是Java语言，而Java的运行离不开Java虚拟机，那么在这种架构下使用Java开发的云函数，性能上能得到保证吗？这个问题我保持怀疑态度，这也导致我在语言方面选择的是Node，而且它也更适合小程序开发者。
  • 虽然无服务与编程语言无关，但是工程师的开发能力与语言有关，代码的规范、设计、管理方面与语言有关。就像老师所说的，做到普适性还有很长的路要走。
  • 由于无服务架构对非业务层（云函数）的封装，一些特殊需求变得难以实现。例如云数据库的封装和限制，使基于云函数的开发、批量数据变得难以处理，函数运行的超时时间限制和数据库对大批量获取的限制等等，都是瓶颈。
  • 无服务架构虽然屏蔽了除业务开发外的实现，但是也对开发人员提出了更高的要求。云函数的实现，需要满足无状态、幂等的要求，否则或许会出现“匪夷所思”的Bug。
  • 当前云开发的各项功能还不完善，开发人员权限的管理、各种资源的授权分配、云函数和云数据库等产品的管理在大型企业的模式下难以适用。

总而言之，云开发有着诱人的优点，但也有一些致命的不足。从架构演化的角度来说，无服务架构未来值得期待，这也是我选择无服务架构的最大原因。

参考资料

https://learn.lianglianglee.com/%e4%b8%93%e6%a0%8f/%e5%91%a8%e5%bf%97%e6%98%8e%e7%9a%84%e6%9e%b6%e6%9e%84%e8%af%be/%e6%98%a5%e8%8a%82%e7%89%b9%e5%88%ab%e6%94%be%e9%80%81%ef%bc%88%e4%b8%8a%ef%bc%89_%20%e6%9c%89%e7%9a%84%e6%94%be%e7%9f%a2%ef%bc%8c%e4%ba%8b%e5%8d%8a%e5%8a%9f%e5%80%8d.md