大家曾经有没有遇过日常技术交流的时候，会讨论某某技术之间的关系是什么，某些技术是否应该用到微服务。我相信热爱技术交流的您，就算不是在微服务这里领域，或多或少都会跟其他同行会做一些争议话题的探讨，而且我敢肯定这些讨论绝对热火朝天。
今天我想从微服务的4个比较火热的话题进行出发，与大家分享我对微服务的一些个人见解，这4个话题分别是：微服务来带的新问题、微服务与SOA、微服务与DDD、是否有必要引入聚合层。这里部分话题，在业界会存在一定的争议性，例如DDD的引入、微服务与SOA的关系。
一千个人眼中有一千个哈姆雷特，不同的人以不同的视角去看待这些问题，都会拥有不同观点与答案。观点上，咱们求同存异，不盲目遵从别人的想法，也不自以为是的把自己当成标准。
当然了，我并不会为了个人见解而故意制造观点与话题，更不会把我所有的观点当成一个“所谓的”标准。因此在该篇文章，我会把多处理收集的资料梳理好放到文内，有理有据地结合自己的见解与大家分享一二。
这些内容可能是大家日常容易混淆的，也可能是大家多次纠结不知道如何做出选择，因此我希望通过我该篇文章的分享，能给大家带来新的观点上的碰撞，或是见解上的共鸣。
最后，我们再来谈谈引入新的技术，给项目带来技术红利。一个新的技术需要考虑学习成本和维护成本，以及可用性保障和可运维性。例如，我在公司在运维的护航下，我可以轻松自如的使用各种技术等，但是，我不一定敢在另外一个公司使用 MongoDB，因为我知道我并不是这方面的运维专家，如果出现问题，我可能没办法解决。那么，引入一个新技术可能存在的技术风险。很多时候，我们要基于失败设计，这恰恰是初级工程师和资深工程师之间的差距。例如，Redis 实现分布式锁，很多人都只想到来如何通过代码实现这套逻辑，但是，如果 Redis 集群中主服务挂了，直接切换到从服务，因为是主从异步同步，而分布式锁讲究的是一定是最新的锁数据才管用，就是在一瞬间才起作用，这时候丢了分布式锁数据，你的业务就会造成重复请求，而分布式锁如果应用在了业务中，必须是非常重要的场景，尤其是金融和支付，所以单点版 Redis 分布式锁不是好方法，不能使用，如果要用，就得解决稳定性问题。（引用《高可用可伸缩微服务架构：基于Dubbo、Spring Cloud和Service Mesh》作者「程超」在群里分享的案例，特别精彩。）这里，小小的偏题了下，回到正题，我们会经常发现新项目尝试使用新技术，而老项目更加保守，因为前者试错成本更低。有趣的是，新公司对技术的发展更加敏锐，例如很多小公司在云原生方面有诸多实践与落地。此时，你可能大概明白了我表述的观点：通常情况下，技术栈的使用背后是公司的运维保障，以及对技术深度的把控力。所以，我们需要对新技术有提前的储备，以备随时上战场，但是绝大多数情况下，我们要保证利用现有的技术（工具）实现业务价值的最大化。 总结一下，本篇文章沉淀了很多我在工作以来的所见所闻和实战思考，核心观点并不是唱衰微服务，而是让大家保持独立思考，跳出纯技术的视角去思考架构，去看待微服务，要保证利用现有的技术（工具）实现业务价值的最大化。
