单体架构中的各个模块隐藏在大系统的页面下，在交付之前对外界是不可见的。更麻烦是单体架构往往是按技术维度进行分层设计，导致没有人能看清全貌，各自都想把事情做到最好，但组合起来却不是客户想要的东西。

微服务强调小、独立业务价值，独立进程独立部署交付，使软件尽快尽早得交付到最终用户手中，来交付和验证业务价值。微服务架构并没有改变软件开发过程中的隐匿性，而是通过缩短从需求到交付这段软件开发周期，减少隐匿时间，来降低软件工程总体的隐匿性。

听起来快速交付很好，但会有什么问题吗?组织必须要具备自动部署持续交付能力。假如一个系统上线需要3个小时进行部署，如果我们要持续部署，每天都部署一次，那就需要每天拿出3小时做部署，我想这个成本是不能接受的。一个全自动化的持续部署平台是必须的，而且还需要保证每次交付都是高质量的，就需要做到全流程内建质量。

这里就引出另外一个问题，由于要求快速交付，atv，就需要打通或模糊软件开发过程的需求、设计、实现、测试、验收、运维、运营等环节，对照以往按照单体架构组织的软件开发流程会发现打通这些过程是有生产力损耗的。比如可以专门做需求分析一个月，不用考虑开发实现，这样更加专注在需求分析当然效率更高了，我们为什么要拉通需求、开发、测试，使得各个环节不专注，生产效率反而下降呢？

在大型软件环境中，各子系统的接口必须协同一致。考虑到时间和环境的演变，要维持这样的一致性通常十分困难。

一个系统在最初开发的时候往往是最舒服的，虽然没有现成的可重用组件，但也没有沉重的历史包袱。假如系统从零开始做的话，头三个月开发会比较慢，因为需要搭建和熟悉一些开发、测试、部署基础设施，随着基础设施和公共组件的完善，atv直播，接下来的半年到一年开发会加速，但是再往后开发速度又会逐渐降低。因为那些一开始提高开发效率的接口、共享表、依赖组件都变成了复杂网络缠绕在一起，变成了所谓的牵一发而动全身，改一行代码都不知道会影响到什么地方。重构也变得非常困难，因为需要相互配合的地方太多了，协同成本极速占据开发成本的比例。

既然一个系统在初步开发、规模不大的时候生产效率最高，要想使得生产效率维持在一个较高的水平，那就保持系统总是很小。这样因为系统本身很小，微服务系统的配合性问题总是在一个可控的范围内。比如微服务独立数据库表结构，那我们根据业务需要改表结构的时候就不需要去考虑会不会影响到其他业务，因为其他业务和这个表结构完全没关系。我们区别看待微服务对外和对内的配合。刚才讨论的单体架构配合性问题都是对内的问题，但微服务架构因为把系统做小，从而把一些原本对内的配合问题变成对外的配合了，极大增加了对外配合性问题。然而单纯从接口协同一致上来说，微服务架构非常糟糕。 单体架构的接口之间配合是相同的编程语言，基本上在编译时就能发现错误。而微服务的接口往往是远程服务，在开发时没法对齐。

微服务控制了对内配合性问题，增加了对外配合性。版本依赖怎么管理、公共组件怎么共享、事务一致性如何协调都是让人纠结的问题。所以微服务的划分就变得非常重要，总体的指导思想是减少对外配合，把复杂的配合性问题留在微服务内部。

软件所应用的环境常是由人群、法规、硬件设备、应用领域等各因素汇集而成，而这些因素皆会快速变化。

单体架构往往需要将所有的模块都整合在一起才能发布，所有模块必须要步调一致。但需求的变化却是不同节奏的，单体架构系统只能强制的把对需求的变化响应放在一个时间点发布，进而使需求得不到及时响应。

单体架构也不能很好的响应性能变化的需求。比如某个模块的流量突然增加，或者需要大内存，单体架构只能为极少的模块增加整个系统的计算资源，又因为增加整个系统的计算资源成本很高、实施时间长，导致性能需求迟迟不能得到满足。