本系列的第一篇介绍了微服务架构模式。它讨论了采用微服务的优点和缺点，除了一些复杂的微服务，这种模式还是复杂应用的理想选择。当你决定将应用作为一组微服务时，需要决定应用客户端如何与微服务交互。在单体式程序中，通常只有一组冗余的或者负载均衡的服务提供点。在微服务架构中，每一个微服务暴露一组细粒度的服务提供点。在本篇文章中，我们来看它如何影响客户端到服务端通信，同时提出一种APIGateway的方法。假定你正在为在线购物应用开发一个原生手机客户端。你需要实现一个产品最终页来展示商品信息。例如，下面的图展示了你在亚马逊Android客户端上滑动产品最终页时看到的信息。虽然这是一个智能手机应用，这个产品

作为一种灵活性极强的构架风格，时下微服务在各种开发项目中日益普及。在这种架构中，应用程序被按照功能分解成一组松耦合的服务，它们通过RESTAPIs相互协作。通过这个设计原则，开发团队可以快速地不断迭代各个独立的微服务。同时，基于这些特性，很多机构可以数倍地提升自己的部署能力。然而凡事都有两面性，当开发者从微服务架构获得敏捷时，观测整个系统的运行情况成为最大的痛点。如图1所示，多个服务工作联合对用户请求产生响应；在生产环境中，应用程序执行过程中端到端的视图对快速诊断并解决性能退化问题至关重要的，而应用中多达数十的微服务（每个还对应数百个实例）使得理解这点变得非常困难。信息是如何在服务中穿梭流动的

“微服务化一词近来热度十足，是人云亦云还是确有两把刷子，本文从三个部分为您详解微服务化改造。业务系统是任何一个用户产品的必须组成，充当着一个门面的角色，用户的输入就是这个系统需要维护的，数据存取是整个系统的核心。例如，广告业务系统的输入是广告主的投放约束、定向条件，微博业务系统的输入是短文字、图片等。在应用发展初期或者规模不大的情况下，有非常简单的实现方案，LNMP、JSP、PyWeb都是你能随口说出来的词，如果用某种架构方式来描述，那就可以称做单体模式（Monolithic，MartinFlower大神所提出的，后面还会介绍），而这些技术都是单体模式的成熟解决方案，它们可以使你工作在“应用层

引言：上篇文章介绍了微服务和单体架构的区别、微服务的设计、消息、服务间通信、数据去中心化，本篇会继续深入微服务，介绍其它特性。通常“治理”的意思是构建方案，并且迫使人们通过努力达到组织的目标。SOA治理指导开发者开发可重用的服务，以及随着时间推移，服务应该怎么被设计和开发。治理建立了服务提供者和消费者之间对于服务的协定，告诉消费者能从服务提供获取到什么样的支持。SOA中有两种常见的治理：设计时的治理-定义和控制服务的创建、设计和服务策略的实施。运行时的治理-确保执行过程的策略。在微服务架构中，不同的微服务之间相互独立，并且基于不同的平台和技术。因此，没有必要为服务的设计和开发定义一个通用的标准

今天开始聊一些微服务的实践，第一块，RPC框架的原理及实践，为什么说要搞定微服务架构，先搞定RPC框架呢?服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦，如下图：服务A是欧洲团队提供服务，欧洲团队的技术背景是Java，可以用Java实现服务;服务B是美洲团队提供服务，可以用C++实现服务;服务C是中国团队提供服务，可以用Go实现服务;服务的上游调用方，按照接口、协议即可完成对远端服务的调用。但实际上，99.9%的公司的团队规模有限，技术团队人数也有限，基本是使用同一套技术体系来调用和提供服务的：这样的话，如果没有统一的服务框架，RPC框架，各个团队的服

基于微服务或者SOA的自动化测试系统每个公司都有自己的特有的，我今天就主要介绍一下，我们研发的一套mock测试系统。我公司目前用的是基于Dubbo的微服务改造，服务之间的调用链路冗长，每个服务又是单独的团队在维护，每个团队又在不断的演进和维护各个服务，那么对测试人员将是非常大的挑战。测试人员每次进行功能测试的时候，测试用例每次都需要重新写一遍，无法将测试用例的数据沉淀，尤其是做自动化测试的时候，测试人员准备测试数据就需要很长时间，效率非常低。目前接口自动化测试框架也多种多样，testng，junit，Fitnesse等，但都需要测试人员具备测试代码编写能力，如果要做好和手工接口测试一样效果的自

今天阅读了两篇关于微服务的文章，总结一些笔记，不敢贸然翻译：一是因为水平不够，翻译的过程会丢掉作者的原意；二是因为技术翻译是一个略微吃力不讨好的活。微服务（microservices）这个概念不是新概念，很多公司已经在实践了，例如亚马逊、Google、FaceBook，Alibaba。微服务架构模式（MicroservicesArchitecturePattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。Micro这个词意味着每个服务都应该足够小，但是，这里的小不能用代码量来比较，而应该是从业务逻辑上比较——符合SRP原则的才叫微服

微服务架构解决了很多问题，但是同时引入了很多问题。本文要探讨的是如何解决下面这几个问题。依赖的微服务调用失败了，我应该失败，还是成功。依赖很多外部服务之后，自身如何保障稳定性。如果所有依赖的服务成功，我才算成功，自身的稳定性就堪忧了。如果调用失败时，选择跳过。那么因此产生的数据不一致性问题如何修复？平时毛毛雨，可以忽略。但是大故障之后，人工还是要来擦屁股的，这个成本就特别高。使用消息队列的最大的意义是在让消息可以在故障的时候堆积起来，等故障恢复了再慢慢来处理，减少人工介入的成本。依赖消息队列做系统解耦的时候，怎么确保消息自身是可靠入队列的？消息是否需要先可靠写入队列，然后再提交数据库事务？如果

2019年多家公司整理的350道Java面试题手册，分布式+微服务+高并发

自包含系统（SCS）与微服务有很多相似的特征。它们都可以独立部署，并以解耦系统为目的。不过，SCS一般具有更粗的粒度和更精确的定义。每一个SCS都是一个自主的Web应用，包含了WebUI、业务逻辑和持久化层。对于SCS来说，API是一个可选项，而且SCS不应该共享UI，当然，那些调用了多个服务的单页应用（SPA）除外。在进行领域驱动设计（DDD）时，为了尽可能降低SCS之间的耦合，每个SCS都应该实现一个边界上下文（BoundedContext）。可以通过对用户故事进行来定义边界上下文。SCS之间可以通过多种方式进行交互：UI集成，如引用JavaScript文件、ESI或SSI；异步通信和事件