12｜云时代的挑战（上）：弹性边界还是业务边界？

本章： 让我们站在产品视角看待这个弹性边界的划分方式。 弹性边界可以为产品提供成本优势，成本优势可以构建护城河阻挡竞争对手。但护城河除了成本还有很多元素，比如创新。那么创新和成本孰轻孰重，这个不好说，得看商业周期的阶段。但大多数时候我觉得创新应该更重要些，创新决定存活，成本决定活得多好。那么站在软件工程的角度如何去支撑产品视角的创新？答案是合理的业务边界与扩展性。这就得出我的观点，以业务为边界比以弹性为边界对于企业发展更有利。但这个观点其实不一定成立，因为它把业务边界和弹性边界划分成非此即彼的对立概念，而现实中，它们是可能划分出相同系统结构的两个视角的决策依据，既合理的业务边界也是合理的弹性边界。如果必须得做个先后，我还是比较推崇业务边界优先，弹性边界随后，创新放在成本前面。引用CEO埃隆·马斯克在财报会议的话：真正重要的是创新节奏，这才是保持竞争力的核心要素。 课后题： 1.弹性边界依旧会有网状依赖的场景，这时候发版的顺序与节奏就依旧要提前规划，唱票执行。 2.服务提供方弹性扩容的滞后会导致服务依赖方扩容的虚高。比如服务提供方10台机器，服务依赖方也是10台机器，这个时候流量是平稳的。然后服务依赖方随着流量激增扩容到了50台，而服务提供方依旧是10台，那么很快服务提供方资源就会被打满。反应到服务依赖方就是大量线程等待，可能会引发服务依赖方进一步扩容到100 150台。（虽然cpu不是强关联资源，内存才是。但是线程的创建也是有内存开销的。如果严控线程上限，那么线程打满时该不该扩容也是个问题）

业务的边界相对比较稳定，弹性的边界不仅和业务有关，也受具体实现的影响，更具动态性，因为流量会传导下去，业务逻辑会影响流量的流向，进而影响各依赖模块的弹性需求。在建模阶段考虑弹性边界是否太早了些，毕竟考虑弹性需求的主要动机是提效降本，这是一个系统优化的问题。为了很灵活的应对各个业务领域动态的弹性需求，将服务拆的更细一些，或者设计是考虑按需部署的需求，支持各个领域服务灵活部署，可以按照流量需求或部署到一起或分开来，会不会比在建模时考虑弹性边界更能有效的应对流量的变化呢？

对大部分应用来说，可能几台机器的扩展就到头了。这种情况下，弹性带来好处非常有限，可能大于带来的复杂度导致的成本增加。

微服务的拆分，认知还停留在原始的功能上下文纬度，质量（部署、性能、可用性）以及康威定律上。理解的“微”不是要多小，而是要系统职责单一 虽然上云了，也知道云的伸缩性，但从没考虑到架构需要跟随更新，前面课程中提到的要保持对架构演化趋势足够关注真不是一句空话，认知被刷新了 软件的变更和部署也是弹性诉求，这倒与现在的一些考虑点相符，也就是从系统迭代和发布频率角度考虑拆分微服务 弹性优先，理解为对拥抱变化的深一层解释，没云时，软件架构不管怎么变，至少所在硬件容器是相对固化的，扩容也那没么灵活，到云时代基础设施都能随流量动态变化了，一切都在变；从弹性优先看我们当前的微服务拆分几乎都是错的，弹性一致的也被拆了好些，更没想过一旦流量暴增，流量传递超成系统整体扩容带来的容器资源超限，似乎没掌握云时代微服务的精髓，真的不如单体架构来得爽快

弹性优先还是业务优先，是不是还要结合业务体量规模、流量去评估，如果是中小规模，微服务也就十几个，应该还是业务优先吧？

受楼上邓志国同学的问答，补充个问题： 2B应用，想做SAAS模式。需不需要做成云，或者，其中的哪些部分适合做成云，哪些不适合？这是最近在思考的一个问题。 采用什么样的布署结构？哪些适合按上下文边界来拆分布署，哪些适合按客户或客户群来拆分布署？有哪些因素影响这个设计决策？

云平台是微服务的前置条件，那么云平台的前置条件是什么？ 从弹性边界角度来考虑是否需要拆分微服务，也就是说某个业务上下文是否值得放入独立的弹性边界，这个的确是一个比较合理的拆分思路，可能还可以结合某个业务是否经常发生变化。

弹性边界可能会经常变化，一个弹性边界会不会突然分裂成几个，这种分分合合，感觉好难hold住

归根到底，在云时代进行业务建模时，我们需要确立一种模型结构以反映弹性边界。同时，在弹性边界切分业务上下文时，还需要确立另一种模型结构，去重建一致性边界。

康威定律劃分的微服務難以避免😪