什么样的软件架构是好的？

“可考核性”是一切的关键。我认为“缺乏可考核性”是现在的软件开发模式最大的危机，这个问题比”无法管理所谓的复杂性“还要更严重。
开发者是无法估算工作量在行业里也不算什么秘密了。这带来了很多根本性问题：

• 因为我们无法知道真正多少人才是必须的，所以中层管理总是比着招聘人头上限，尽可能的加人。为什么会这样做简单，他们的薪酬和他们所管理的人头数是成正比的。

• 把软件重构得”更可维护“没有商业价值。什么叫可维护性题如果解决不了，扔更多的人进去总是可以解决的。软件工程又不是造火箭，能有多难本无法证明重构可以节省多少人力，因为就没有可对标的重构前的应投入人力。

要解决这个问题，我认为不是去搞明白开发工作量的评估的魔法。恰恰相反，如果我们和业务负责人是以同一个团队的方式来工作，我们就压根不需要去估算工作量。每个软件开发团队都有应该有“唯一的一个”对应的业务团队，业务团队背什么样的OKR，技术团队就背什么样的OKR。要让团队可考核，最重要的是只对一个业务负责。

在大的尺度上，架构就是分解Bounded Contexts（参见领域驱动开发，DDD）。这就是把业务的组织架构图体现到软件的世界里：

虚拟空间和智慧体

一个Bounded Context对于一个团队来说仍然太大了。至少在微服务的心智下是这么认为的。如何把它进一步分解为更可管理的小块呢的模型是“虚拟空间和智慧体”。我们做为程序员所做的事情，简单来说就两个：

• 虚拟空间

• 有点智慧的“机器人”和我们人类一起在虚拟空间里交互

虚拟空间和我们肉身所处的物理空间是一样的，它都是构建在因果关系上的。有两种法则主导这些因果：

• 自然法则：大自然自身的内在规律

• 会法则：一个人造的体系，人们通过模仿自然法则创造出类似稳定的规则系统去构建稳定的 会秩序

所有权==著作权

“虚拟空间”这部分仍然太大了。业务流程可能会有很多个步骤，例如：

可考核性问题的根源是编程语言里缺乏对完整因果链的直接描述能力。我们可以在白板上画一个清楚的业务流程图，但是在写代码的时候就不需要切分成很多细碎的服务和函数来表达。之所以工作流引擎总是被拿出来考虑，因为它的描述能力和要解决的问题有良好的映射。但是BPMN并不是一种编程语言。
步骤与步骤之间有很强的因果关系。在产品详情页展示的促销，也应该体现在购物车里，也应该体现在收银页面上，也应该体现在最终的收据里。我们使用的“function”的概念，顶多只能用来描述500ms内发生的事情的因果关系。对于前面所述的业务流程，我们切分成了很多个步骤，同时又按照使用方的不同，切成成了很多个面向用户的服务。从而因果关系就被隐藏在这些庞杂的实现细节之中了。软件跑起来就像一场接力赛，一个服务把职责接过来，搞一搞之后，又传递给另外一个服务。理想的情况是，代码本身就应该体现流程图，读起来就像流程图。
更糟糕的是，现在的切分方式并没有明确的划线的原则。这就频繁导致了团队之间关于谁应该负责什么的争论。高度政治化的组织氛围导致了开发者情绪上的沮丧。同时，具有讽刺意味的是，在大家彼此抢活的同时，又因为职责切分得太碎，导致又没有一个团队能够对全局负责。
对于解决这个问题，目前能够做到的“最佳实践”就是在一堆微服务团队上架一个门面团队。“所有权==著作权”，我们只愿意对自己所写的东西负责。这个人性，无法改变。为了给这些可怜的家伙具有所有权的感觉，我们必须允许一层很薄的代理层，或者叫所谓的调度服务来把微服务给“屏蔽”在后面。但是这种代理一层的做法经常导致了很低的团队自主性。
理想的编程语言，应该能够提供“function”一样的东西去直接描述业务流程。业务上的同时行进的并发流程应该可以像多线程编程一样，用消息传递的方式来描述。这样，我们可以给每一个可切分出来的业务流，分配一个独立的软件团队去端到端负责。他们可以对自己负责的事情100%负责。这些人和业务运营人员，以及编写出来的“机器人”合在一起作为同一个团队，共同负责这个业务流的收益和亏损。而不是单独把技术摘出来，成为一个共享的成本中心。

协作单元

除此之外，还有一个事情是有问题的。之前由编程语言提供的模块化单元，例如assembly/package/class这些，就是我们团队之间彼此协作的单元。然而现在不是这样了。现在越来越多的人，要求软件模块有独立版本，能够独立的部署。因为这样才能支持多个团队的独立性。这就导致了大量的微服务的做法。
但是我们是否“总是”需要用不同的编程语言不同的工具来实现微服务言的差异和彼此割裂的工具导致跨团队沟通更加困难。你可以拥有你的流程，拥有你的服务，但是这不阻碍你和你的伙伴们用同一门语言啊。一门编程同时扮演了3个角色：它连接了机器，它连接了开发者，它同时又连接了团队。今天编程语言更多是仅仅作为一种连接机器和开发者个体之间的工具，团队之间宏观上是彼此割裂的。
解决方案应该是把软件作为一个整体来思考，而不是被狭隘的“操作系统进程”的视角给限制了。构建新的微服务的成本，应该和后台用function启动一个线程没有多大区别。理想的编程语言里，我们有各种各样的function，但是执行机制不同。
原文链接：https://zhuanlan.zhihu.com/p/46372932

基于Kubernetes的DevOps实践培训