一周技术学习笔记(第77期)-组织架构活动

本期6个话题。

| 话题1：

一般认为架构师的主要职责首先是组织架构活动，然后是制定架构方案。制定架构方案我们一般都能很好的理解，那什么是组织架构活动呢。

架构活动都有哪些呢？

偿还技术债：不论什么样的类型的团队，初创也好，成熟也好，往往我们都一直面临着交付压力。这种情况下我们的程序员写代码有时候比较随意，什么“意大利面条”样式的代码都有。我要交付的快，请允许我有这样的“犯罪”，我以后再补还不行么。其实大多数时候都没有以后。实在不行，我们常常把敏捷开发拿出来“顶罪”，咳，你说，敏捷开发在帮助业务高速迭代的时候，也导致了大量的短期行为，这种短期行为的结果，往往就是技术债。

拉通认知差异：比如我们搞业务建模，有的团队认为必须采用统一的工具画图，而且必须是UML图；有的团队认为建模就是一个抽象，我们只要实现一个可视化沟通就够了，无关用什么工具，什么图形；有的团队认为程序员的唯一产出就是代码，模型再好，图画的再好不过是一个过程，最终你要交付，代码就是你的唯一，万一你说的（画图）和做的（代码）不一样呢。

协同大规模项目：现在每个团队的开发模式都是微服务的方式，微服务的优势就是服务之间可以独立变更。只要服务之间的API相对是稳定的，那么我们系统之间的协同频率就会降低。可是，在一个企业里面，我们往往会做一些公司战略级别的项目，比如我们的618大促、春晚红包，还有其它公司大型项目，那么这个时候制定和协同跨团队的统一交付流程和节奏就有了挑战。

上面这些需要架构师来参与的活动，有的是因为我们的开发模式决定的，有的是大家的认知参差不齐导致的，在一个以分布式技术为主的互联网研发活动的环境里面我们要时刻清楚团队面临的各种问题和挑战。

而这些挑战都在这些活动里面，理解了这些技术活动，在这些活动中制定好解决方案，架构师就能够明确自己的定位：什么事情是自己应该做的，什么事情是其他参与者应该做的。

| 话题2：

2003年 Eric Evans 写了《领域驱动设计》，但Eric传播知识的能力一般，这本书的质量也一般，于此同时在国内也没有掀起波澜。但是这期间国外论坛人们会经常的讨论起DDD，十年之后的2013年，Vaughn Vernon 将十年的精华重新整理，写了一本《实现领域驱动设计》，这本书质量要好过十年前的那一本。无奈《实现领域驱动设计》这本书太厚，给不大愿意看书的同学竖了个高门槛，于是Vaughn Vernon 又出手写了一本精华本《领域驱动设计精粹》，这本书就薄了很多，有更多的人愿意去读，但读着读着你会发现很多内容不够劲，于是这些人又反过来去读那本当初厚厚的《实现领域驱动设计》。

2014年James Lewis 和 Martin Fowler 写了一篇文章，其中给了微服务一个更清晰的定义，把它当作了一种新型的架构风格，之后微服务大火。

| 话题3：

问：你为什么要采用微服务？

答：因为系统体积小，代码相对容易理解，测试也相对简单，部署也容易。

其实，这个问答中的答案是结果，也就是做好了微服务之后的结果。当然回答的没有问题，可是我们该怎样达到这个状态呢。

好，也容易。

我用Spring Boot快速搭建服务，我用Spring Cloud建立分布式系统，我用Service Mesh技术作为服务的基础设施，我用....，是的，服务技术发展到今天，我们有很多工具，有一个全家桶，但这也仅仅是工具。是术的东西。

微服务最难，最有价值的部分，并非是你用了什么技术来实现，而是业务划分。一个业务划分清晰的微服务，系统之间耦合低，没有大量的相互调用，开发人员之间耦合少，没有频繁的扯皮。只有业务划分清晰了，才能实现真正的微服务，而不是伪服务。

| 话题4：

WEB的三种运作范式。

WEB1.0，平台创造，平台所有，平台控制，平台收益。

WEB2.0，用户创造，平台所有，平台控制，平台分配。

WEB3.0，用户创造，用户所有，用户控制，协议分配。

很显然，WEB3.0更“共产主义”些。

WEB3.0的主要目的就是：

重新组织整个互联网的产业链条，按照数据产生、数据存储和数据使用的具体分工，明确数据归属、实现数据价值、完成利益分配，并建立可以实现上述目标的基础设施和生态体系。

| 话题5：

我们可以把系统分解为两部分，一，和运营无关的部分，二，提供运营能力的部分。和运营无关的部分，比如Google的搜索引擎，腾讯视频的流媒体，提供运营能力的部分比如广告的投放和竞价，VIP账户等。和运营无关的部分不怎么需要业务方的输入，提供运营能力的部分则需要业务方的输入和验证。在进行建模时，针对与运营无关的部分和与运营有关的部分，我们需要处理的核心复杂度并不相同。

复杂度又分为本质复杂度和偶然复杂度，本质复杂度是你无论如何都要都要处理的事情，比如广告的投放和竞价，而偶然复杂度是我们效率低下的原因，比如用Struts1来实现投放和竞价的web工程，选错了工具或者代码不合理的设计，都导致了偶然复杂度。而我们大部分程序员整日忙碌解决的问题大都是由偶然复杂度引起的，因为本质复杂度无论你碰与不碰都在那里。

| 话题6：

这世界本就没有任何一句话，

可以让你醍醐灌顶。

真正叫你醍醐灌顶的，

只能是一段经历。

而那句话，只是火药仓库内划燃的一根火柴。

--知名作家

参考资料：

https://zhuanlan.zhihu.com/p/438429878

https://time.geekbang.org/column/article/549701

https://time.geekbang.org/column/article/488727

----END----

这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。