gydtep
发表于 2020-8-7 15:49:14
维护成本：随着时间的推移，给软件增加新功能就会变的越来越难，越是运行长久的项目就会陷入重写还是重构的苦恼。
gydtep
发表于 2020-8-7 18:51:42
这是与 hardware 所对应的。我们希望“软件”能够进行快速的修改，应该能够快速响应甲方或者客户的需求，
gydtep
发表于 2020-8-7 20:23:09
所以软件架构必然不像建筑架构一样，建筑一经建成，修改的成本极高，而软件应该走对应的方向，发挥易于修改的特点。
gydtep
发表于 2020-8-8 12:23:10
所以，回正我们的视野，当我们决心要设计一个好的架构时，我们需要明确，架构往往决定的是软件的非功能性需求。
gydtep
发表于 2020-8-8 15:49:33
易于运维：DevOps 的初衷是建立一种缩短运维与研发距离的文化，让出现问题后更容易处理，希望让大家将视野放在产品上而不是限定自己的工种，
gydtep
发表于 2020-8-8 16:02:51
这并不是期望运维的同学能够成为 Java 专家，迅速的进行 heap 分析发现问题，我们强调的是运维时的闭环能力。
gydtep
发表于 2020-8-9 11:49:40
即那些非功能性需求。也有人使用 pattern 来描述它，也有人说和 SOA 基本上是一个东西，只是粒度不同，
gydtep
发表于 2020-8-9 17:40:40
这里并不想展开讨论它的好处，我们先考虑投入成本。假设我们每个同学都完整的学习了微服务的所有知识，对市面上的框架、产品非常熟悉，摩拳擦掌准备开始，
gydtep
发表于 2020-8-10 09:14:16
因为足够的界限上下文（bounded context）能够保持服务的独立性，使其细节被隐藏在界限之内，听起来是个不错的主意。
gydtep
发表于 2020-8-10 10:27:23
这些微服务调用单体所提供的 API 来完成功能。对于常常出现的市场活动（比如某个体育比赛的专用板块），这种方式能够快速实现活动页面与功能，完成业务需求，
