软件架构即取舍

这个世界上不可能有通用的架构，一切都是取舍的。

任何软件的设计都需要明确定义要什么不要什么，任何软件都会有缺陷，这个世界不存在完美的事情。

对于一个问题不会只有一种标准答案，解法多种多样，因为不同视角、不同关注点看待出的问题是不同的。那么解法也就多种多样。

任何技术任何设计都有其使用的地方和场景，所以脱离了场景谈软件设计或者架构设计是不科学的，这是纸上谈兵的做法，不是工程师的做法。

工程师解决问题的第一件事情是了解要解决什么问题，这个问题的本质是什么，这个问题可不可以被简化和抽象，之后再根据场景需求来挑选合适的正确的技术。

微服务的架构有什么特点呢？

优势是开发快、部署快、隔离性好、功能扩展方便，但集成测试、运维、服务管理麻烦大一些。所以微服务架构需要有一个好的PaaS平台，这样才能用好微服务。

程序的本质是：控制逻辑+业务逻辑，控制逻辑是和业务不相关的逻辑，就是让系统支持的更加稳定和快速，我们一般叫做非功能性能力。而功能性能力也就是业务逻辑，他的产生是来自于业务需求的变化。

所以在系统设计过程中，很重要的一步就是要区分系统的功能性逻辑和非功能性逻辑，并且要建立比较好的隔离措施，防止一些低水平的工程师将两者轻易混淆在一起。一旦将两者混淆，系统的复杂度就会上升，很多稳定性、技术债就此埋下。

绝大多数的系统复杂度是由于业务逻辑与控制逻辑纠缠不清。

很多程序员分不清什么是Logic和Control。

Control是可以标准化的，他的主要面对场景是数据的处理，这些东西不需要太多的差异化，标准最好，但不要脑补出一个不存在的标准，聪明的程序员不太需要在这里浪费太多时间解决差异化问题。

Logic是存在差异化的，有可能来自于业务发展阶段的重点的变化，有可能来自于上下游兼容逻辑的处理，总之存在一定的差异化，怎么做呢？就是低成本的解决差异化即可。

因为Control是可以标准化的，而Logic是难以标准化的，所以不要妄图在Logic投入太多时间要求标准化，一种情况可能是得不偿失，另一种情况就是根本解决不了，这一阶段的所有投入在下一阶段都会变成新的问题。

所以要做好Control、Logic、Data的分离与抽象，在脑中要有一个清晰的定义，思维决定行动，思维想不到，根本做不好。一个人的潜力是由思维决定的，有的人沟通下来就感觉潜力不高，尽管很努力，也不过是提高下限，上限难以冲破，所以想明白、怎么想很重要。

一个系统的复杂度的上限是由业务逻辑决定的，如果业务逻辑太复杂，是不能通过控制逻辑来简化的，而系统的复杂度下限是由控制逻辑决定的，好的控制逻辑可以尽量让研发人员关注于业务逻辑与业务需求同频，而不是在系统演进过程中投入过多精力却解决稳定性、性能、分布式等非功能性问题。

微服务架构体系下是同时解决控制逻辑和业务逻辑的，所以服务拆分过程中一定要关注于业务逻辑的合理性，如果忽略了业务逻辑的复杂性，而做微服务的强拆，最后会发现业务逻辑和控制逻辑交织不堪，导致整个系统复杂度奇高无比。

所以对于一个复杂业务体系下进行微服务拆分时，首先要做到是业务逻辑的简化和模块化，而不是直接做微服务的拆分，因为在这个阶段微服务帮不了你什么忙。

说实话我可能没有见过所谓的真正的微服务架构是什么样子，因为服务在每一年中都会经历合并与拆分，合并也好，拆分也好，背后给出的逻辑都是相似的，当时的解决方案，在下一阶段变成了新的问题，变成了拆分的原因与理由。

所以我更多的将这些看做是服务化系统，而不是微服务，因为拆分出的微服务单元很难服务好业务发展。

比如大家讨论云原生概念，Serverless和FaaS是其中谈的最多的，但用好Serverless和FaaS是需要和其他服务很好结合才行，而且需要有很强的业务实践。

现在的很多云原生解决方案其实还是在中心云执行的，那么很多人就会觉得新瓶装旧酒，带来的价值不大。但我觉得这个背后的根本原因是在于对于云原生的理解上有歧义导致的。

没人说云原生一定是在中心云，想想，如果Serverless和FaaS能力用在边缘云计算场景上，这事是不是很酷？

比如在CDN上，5G基站上，或者在APP上，比如banner对于不同地方的用户展示不同的内容，这事其实是一小段函数要做的事，而且业务逻辑简单，没必要耦合到业务逻辑中心或业务领域中心，用Serverless和FaaS这样的技术就很方便。

所以Serverless和FaaS这种在微内核之外的旁路逻辑上有很好的生存价值，不入侵业务内核，也可以做很好的旁路边缘适配。

而如果是一家IOT企业，这事就天然的成了。不需要用中心云这么笨拙、不实时的方法，在边缘节点做一些简单的处理，即实时成本也更低。它适合边缘计算。