微服务之旅的经验分享

   <p>多年来，我们一直努力展示众多微服务实践者在采用微服务的过程中获得的经验和教训。 Piotr Gankiewicz 是一名软件工程师。他踏上了 微服务之旅 ，现在决定分享一些过程当中的 经验和教训 。当然，就像所有的经验一样，它不是全都与你的实践相关，但是这些经验和教训还是值得了解的。正如Piotr说的：</p>    <p>不久前，我终于决定深入到 微服务 的世界了。我确实花了相当长的时间寻找使用这种架构模式的机会，并最终找到了。在经过三个月的尝试和学习，其中大部分都是自学（困难的方式），我相信是时候分享一些经验了。</p>    <p>他从讲述一些核心的系统设计方面开始，其中包括API管理（gateway）。他引入了“服务总线”的概念，而没有真的定义它。他还讨论了存储服务的添加：</p>    <p>[...] 为了在只读数据库（这里就是CQRS一类的东西）中存储对象，你很可能需要订阅所有类型的事件，像UserCreated和InvoicePaid等等。然后你需要与特定的（微）服务通信获取数据，然后将它存入数据库中。在这种场景下，你的API需要负责订阅事件、映射数据和保存数据到数据库。这有问题吗？ 多数情况下当然没有。但是，我更倾向于下述解决方案。它将API和微服务完全分离。这样，就出现了所谓的存储服务，由它来订阅事件，从（微）服务获取数据等等。存储服务知道怎样扁平化数据。API只需要给存储服务发送HTTP请求来获取数据。它并不需要关心数据是从哪里来的，是内部的数据库，还是缓存，还是处于天涯海角的某个服务。</p>    <p>最后在给出他的经验和教训（他称为“小贴士和窍门”）之前, 他用对服务的定义总结了设计方面。服务的部分定义包括：</p>    <p>每个（微）服务处理自己的领域模型、仓库、业务逻辑等等。整个基础服务唯一共有的是服务总线和一套命令和事件集合。</p>    <p>那么回到小贴士和窍门。我们这里只包含其中一部分。对那些认为微服务的大小重要的人，首先是“让服务尽量小”。</p>    <p>创建多个小型的专注于单一领域的微服务比创建少量臃肿的执行完全不同任务、在相同的范围内管理不相干职责的微服务要好。最常见的例子有：创建/验证用户账户、 发送消息、管理产品、处理支付等等。每个领域纳入到单独的有独特实体的服务中。</p>    <p>从别人对 微服务、事件溯源和CQRS 的说法展开，Piotr认为CQRS至关重要:</p>    <p>遵循CQRS，你需要做的全部事情是发送无返回值的命令和执行幂等的查询。如果你遵循这一模式，你会很快发现扩展应用程序简单多了，只需要分离读写操作。</p>    <p>接下来回到数据。为服务选择数据库的方式至关重要。这再次和其他人讨论的相似：</p>    <p>每个服务（不是单个服务实例，因为你可能有许多同一服务的实例运行在不同的节点上）都应该有自己的数据库。这样你不仅能消除单点故障（整个系统使用单一的庞大数据库） ，最重要的是还能自由选择最适合特定任务的数据库。你可能想使用SQL执行严重依赖事务的金融操作，或者使用NoSQL数据库存储数十亿JSON文档。</p>    <p>Piotr提到了其它一些事情，如请求追踪（他举例说明了在他的学习之旅中的实现方法 ）、使用异步消息方法（使用HTTP）、确保新服务易于部署（可能隐晦地引用到持续集成和持续部署）以及编写端到端测试。最后提到的是“包含故障恢复、服务发现和其它一些有用的机制"。</p>    <p>任何时候出错了，你可能希望保证整个系统不会崩溃或者至少其中一部分不会崩溃。确保你引入了重试机制（比如 Polly ）、服务发现工具，如 Consul 以及集中保存证书，比如使用 Vault 、 Azure Key Vault 或者我的开源项目 Lockbox 。</p>    <p>Piotr讨论的大部分和过去这些年别人说的非常相似，所以在使用微服务开发时我们很可能正趋向一个关于方法有效还是无效的共识。但是需要注意的是，尽管Piotr讨论了他的一些经验和教训，但是没有任何关于他开发的应用程序表现如何的说明（负载下扩展、恢复能力等等）。可能后期会有，我们拭目以待。</p>    <p> </p>    <p> </p>    <p>来自：http://www.infoq.com/cn/news/2016/12/microservices-journey</p>    <p> </p>