不得不说，这是一本难得的，洗尽铅华的书，并没有因为写微服务架构，而对其进行过分地鼓吹，里面有两句话，说得确实很有道理。
架构就是取舍，架构师就是做出取舍的人
著名的“CAP定理”，是一种三者选其二的取舍，比如：Redis Cluster选择了高可用，牺牲了一致性；Hbase集群保证了强一致性，却放弃了高可用。
Redis的LRU算法，是用随机采样法+淘汰池的近似LRU的方式，节省了内存空间，却牺牲了一些精准度，同样是一种取舍。
我们在设计数据库表结构的时候，也用采用增加冗余字段的方式规避多表关联，这是用空间来换时间的取舍。
结合于当前的系统特性，以及客观存在的外部情况，没有最好的架构，只有最适合的架构，因此需要我们的架构师经常要面对取舍、做出取舍。
没有任何一项技术可以被称为“银弹”，微服务架构也不是“银弹”
这种现象，就像是前两年的“忽如一夜春风来，包治百病叫中台”，做程序开发的，不拽两句中台，就跟被时代给抛弃了一样。但如果追问一句：“中台和平台的区别是什么？”估计得有80%的人支支吾吾地答不上来。
微服务架构也不是“银弹”，我完全不建议，如果你毕业设计做一个网上商城，一定要用微服务的方式搭建。同理，如果创业团队的两三个人，在零积累进行业务试错的情况下，快速地搭建一套业务系统去试错，我也强烈不建议一上来就把系统先微服务化，并宣称“为项目留足了扩展性”，或者“做了未来几年的架构设计”。因为，系统架构一定是演进过来的，不同时期，不同团队情况，会适用于不同的系统架构。
书中所写的微服务优点，逐条分析：
更好的容错性：
这个应该毫无争议，如果A服务本身或其所属的数据库由于资源耗尽被打挂了，或者响应时间被拖得很长，不会影响到B服务和C服务，但如果ABC服务的业务都在一个单体应用里面，那就一挂全挂了。
不过有一点需要注意的是，无论你的微服务拆分得如何彻底，最后大概率还是上面有一个聚合服务，负责把若干个底层微服务的数据获取过来，然后重新进行加工组合，最终返回给端。类似这样：
因为底层微服务的容错性是微服务架构天然具备的，那么聚合层的容错，这不是用个微服务架构就可以解决的，其实这是非常看工程师能力的。
比如：如何区分强弱依赖，如何合理设置超时时间？超时时间是设置一个整体的，还是根据不同的下游服务分别设置？面对非强依赖的下游，出现超时或者异常如何处理，降级还是熔断？面对下游强依赖，如何做好Plan B，甚至在牺牲一些的设计原则的情况下，做好Plan B？在最极端的情况下，如何做好MVP（最简化可实行产品）？
更容易实现和接纳新的技术
如果某种新的技术是在某个服务内小范围使用的话，那么只要维护这个服务的几个工程师达成一致即可，属于工作范围内自治，有了更多的自主性。
如果某种新的技术，全公司范围内推行的话，情况会复杂一些。对于任何新的技术，一个严谨的工程师团队都是抱着起初怀疑和敬畏，逐渐地实践和理解，最终完全掌握和建立信任过程来的。
因此，微服务架构正好适合我们从一个服务到多个服务，从非核心服务到核心服务的推行试错过程。若是像SOA这样较大的单体应用，一换全换的话，因为推行新技术而导致系统整体故障，这个试错成本可就太大了。如果是上线之后马上发现问题还好，最怕的就是，上线后暂时没有问题，又上了几个版本的业务需求，然后发现问题了，这个时候回滚的代价就变得更大了。
硬币的两面性，如果某种新的技术，全公司范围内推行的话，一个一个服务地去改，时间成本肯定要比像SOA这样较大的单体应用高很多。
使大型的复杂应用程序可以持续交付和持续部署
书中从三个方面来论证的，简单总结如下：
- 可测试性，因为每个服务都比较小，因此执行自动化测试比较容易，且程序bug也会相对较少。
- 可部署性，修改的服务独立部署，不需要与其他模块的工程师协调，即可进行。
- 团队自主，松散耦合， 每个团队可以独立于所有其他团队开发、部署和扩展他们的服务，开发速度变得更快。
结合我多年一线开发和架构设计的经验，以上条件满足的话，业务需求所带来的改动范围足够可控，且应该是以下几种场景中的一种：\
① 扩展类接口，上线后暂时没有流量\
② 接口位于调用链的最上游，无其他微服务调用，端上可见\
③ 修改类接口，但接口本身并不重要，允许试错
④ 修改类接口，且是核心接口，但是修改范围小，风险可控
⑤ 修改类接口，且是核心接口，在业务的绝对低峰期上线，允许试错
举两个反例：
① 基于电商模型，最重要的服务之一，商品中心改了一个核心接口，且改动量大，该接口被用户端和商家端的多个系统调用，业务流量大，没有明显的低峰期。
这种情况下，你敢跑个自动化测试，不惊动任何调用方，直接部署上线吗？且，这也不是小概率场景吧？
② 基于电商模型，商品需要增加一种新属性，于是在商品的供给侧加了一个字段，且围绕着这个新增字段，有业务逻辑需要修改，那么商品的供给侧、商品中心、订单中心、促销平台、用户端、商家端，整体都需要修改，改动完后，需要跟上下游进行跨服务联调，然后再部署到测试环境和预发环境进行测试验证，在这过程中，还要伴随着微服务最另人头疼的跨多个服务的问题排查，最后再按照顺序把各个服务推上线。
**这种情况下，可测试性、可部署性、团队自主、松散耦合，是不是都无从谈起了？至于开发速度变得更快，微服务架构的整体跨服务大联调、问题排查、测试环境搭建部署，以及多服务按顺序上线，跟像SOA这样较大的单体应用相比，是不是更浪费时间？**且，这也不是小概率场景吧。
不过，微服务有一个最大的优点，它绝对重要，我们下次再谈。
未央。
