在微服务架构下，给我们测试带来了如下挑战： 验证成本高，为了验证多个服务协作后的功能正确与否，需要为每个服务搭建基础设施（包括数据库、缓存等），并执行部署、配置等步骤，以确保服务能正确运行。 结果不稳定， 分布式系统，服务之间的通信都是通过网络调用，然而在网络上传送，都会面临网络延时、超时、带宽等因素，容易导致不稳定的测试结果。 反馈周期长， 相比单体应用而言，微服务架构下，可独立部署的单元多，因此集成测试的反馈周期比之前会更长，定位问题的时间就会更久。 沟通成本高， 微服务常由不同团队开发并维护，当服务频繁进行改动和版本升级的时候，很容易导致不兼容，加大团队之间的沟通成本。 测试金字塔 测试金字塔很好的帮助我们在制定测试策略的时候，区分不同层次测试关注点，同时，一般来说，测试颗粒度越粗，越脆弱，执行的时间越长，维护成本也越高。 不得不说的契约测试在微服务中，不得不聊聊消费者契约测试， 契约，一种定义在Consumer与Provider之间的交互方式 消费者驱动的契约测试 契约是Consumer和Provider团队之间达成的交互协议，更多的看中的是请求和响应的Payload结 ...

Spring Cloud 发布于2015年3月 引入NetflixOSS的开源技术栈 基于Spring boot 构建了分布式系统的公共模式 Spring boot是Spring框架对“约定优于配置”理念的最佳实践的产物，比如自动配置，它背后通过了Springfactoriesloader，它属于Spring框架私有的一种扩展方案（类似于Java的SPI-Service provider interface）， 其主要的功能就是从指定的配置文件meta-inf/spring.factories加载配置。 常见的微服务组件 服务端负载均衡 HTTP重定向负载均衡（类似DNS域名解析负载均衡） 优点 实现比较简单 缺点 浏览器需要两次请求才能完成一次访问 性能较差 重定向服务器自身的处理能力有可能成为瓶颈 反向代理均衡器的优点（以Nginx，HA Proxy为代表） 比较简单 可以利用反向代理缓存资源 改善网站的性能 反向代理均衡器的缺点 所有请求和响应的中转站 其性能可能会成为瓶颈 数据链路层的负载均衡优点 不需要修改数据包的源地址 响应数据不需要通 ...

什么是单体应用？ 如图所示，这个系统采用了三层架构，表现层，业务逻辑层，数据访问层，虽然三层架构解决了应用程序中代码间调用复杂，代码职责不清的问题。但是他只是将应用在逻辑上分成了三层，并不是物理上的分层，通过编译，打包，部署后，最终还是在同一台机器的同一个进程中运行， 这种功能集中，代码中心化，一个发布包，部署后运行在同一个进程的应用程序，我们通常称之为单体架构应用。 单体应用的优点？ 易于开发 易于测试 易于部署 单体应用的弊端？ 维护成本高 - 随着业务的不断扩大，需求的持续增加，越来越多人加入开发团队，代码库也在急剧的膨胀，在这种情况下，单体架构的可维护性，灵活性在降低，而维护成本，技术架构演进的成本，以及系统扩展成本等都在增加。 可靠性差 - 由于所有模块都运行在同一进程中，任何模块中的一个 bug，比如内存泄漏都可能弄垮整个进程。 技术选型成本高 - 单体应用会让采用新框架和语言极其困难。举例来说，你有两百万行使用 XYZ 框架的代码，如果要使用 ABC 框架重写代码，无论时间还是成本都将非常高昂，即便新框架更好，这也就成为使用新技术的阻碍。 交付周期长 - 一般采用rel ...

DDD是什么？ 领域驱动设计是一种处理高度复杂域的设计方法，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队应用它可以成功地开发复杂业务软件系统，使系统在演进时任然保持敏捷。 另外一种解读：DDD不是语言，不是框架，不是架构，而是一种思想，一种套路，它可以分离业务复杂度和技术复杂度，DDD也并不是一个新的事物，它是面向对象的拔高，最终目标还是 高内聚，底耦合 DDD主要解决的问题？ 如何合理的划分业务系统？这为微服务的划分提供了方法论（微服务的粒度的问题，多大算大，多小又算小，在微服务刚兴起时，很多企业或者架构师对它都没有统一且明确的定义，这里给些examples，e.g：代码行数？职责的划分？披萨原则？组织结构？）界限上下文很好的回答了这个问题，这也是DDD最近几年借微服务的东风，火起来的原因之一(领域驱动设计的提出距今已经十多年，但真正火热起来大约是在2013年微服务架构被提出来之后)。 如何保持业务架构和系统架构的一致性？与传统的系统相比，DDD里面强调领域专家和技术团队的合作，建立统一语言“普通话”， 聚焦在 ...

定义 Event-driven architecture (EDA), is a software architecture pattern promoting the production, detection, consumption of, and reaction to events “Event (computing)”. 简单来说，事件驱动架构就是基于事件进行通信的软件架构，它具有以下的特点： 分布式异步架构，事件生产者和消费者高度解耦（生产者不知道有多少消费者要消费对应事件），事件消费者之间也高度解耦（消费者之间也互不感知） 更好的性能，由于事件的异步本质，软件不易产生拥堵，能够处理更高的流量。 事件处理器可以独立的开发，测试，部署，并容易接入到整个生态系统，故可扩展性好。 Orchestration vs Choreography我们在聊事件驱动架构时，先了解下Orchestration 和 Choreography的区别： 他们都是服务组合的方式，一种是中心化的方式，另外一种是去中心化的方式，直接从下图就可以看出他们之间的区别： 在上一篇文章里面已经介绍了， ...

定义 Synchronous: A business transaction done in a single HTTP request/response exchange, which means that the HTTP response provides all data and associated resources resulting from the transaction Asynchronous: A business transaction done over multiple HTTP request/response exchanges, which means that the initial HTTP response does not provide all data and associated resources resulting from the transaction, such data and resources can be obtained in subsequent interactions. 问题域HTTP是一个同步协议： ...

定义 API是Application programming interface的缩写, 即应用编程接口，一个系统可以通过API，暴露自己的系统的业务能力和数据，为其他应用赋能； API一直作为软件工程里面的重要组成部分，由于“API economy”和“Open APIs”的概念，API在企业资产中占有越来越突出的地位，甚至可以说提到了企业技术战略的高度。 一些典型的应用场景 在遗留系统或者服务上面，包装一层更加现代的技术，提高其易用性，降低消费者的使用难度。 在流程自动化的时候，需要Build，Deploy软件或者创建虚拟机, 容器等。 封装datasource，暴露数据。 抽象化业务能力，e.g：在保险行业里，购买保险的时候，获取报价API，这样使用者就不需要知道底层或者背后是如何实现的。 一些主要的收益 如果API对外的接口不变，那么作为使用者，我是不关心你如何实现的，这就给服务提供者，提供了很高的灵活性，做到了具体实现和消费者之间的解耦。 通过合理的API划分，可以将一个很大的系统，分解为由N个API组成的系统，整体统一对外服务，这样方便了多团队的开发和交付。 如果有合适 ...

背景很多团队都在构建API，并且声称自己团队创建的API都是足够的RESTful，今天我们简单聊下RESTful API相关的一些概念和设计实践。 定义 REST(Representational State Transfer) - 表述性状态转移 简单一句是就指： 服务器发送表述用于描述资源的当前状态，客户端发送表述用于描述客服端希望资源拥有的状态。 REST 是一种架构风格。定义了分布式系统中，各个组件之间的交互方式。 Richardson成熟度模型 LEVEL 0， 只用HTTP作为传输通道，不会使用HTTP的任何额外机制。例如SOAP、 RPC LEVEL 1， 引入资源的概念，使用不同的URI完成不同的功能。 123456789101112131415161718GET /books?author=“john”Response:[{“id”:11, “Game of thrones”},{“id”:22, “Notre Dame de Paris”}]GET /orders?action=create&bookId=11 ...

当我们在为新的产品或者项目进行系统架构设计、制定演进路线、技术选型的时候，我们需要一些架构原则，来指导我们的架构设计和选型。 架构解决的问题架构作为构架在业务与技术之间鸿沟的桥梁，e.g：业务需求 –> 架构 –> 技术实现其主要目的： 为了解决当下或未来软件系统复杂度带来的问题，而架构其实并非设计出来，而是随着业务的发展逐步演变出来的结果 架构的一些原则1.Security - Built security in， “安全”带来的品牌名声损失、用户流失、金钱的直接损失，都是企业级应用不能容忍的事故。 可参考的实践： 端到端的加密，传输的数据通过SSL加密，e.g: Request -> ELB(https) -> EC2(https) 根据系统不同的用途，将各个系统进行网络分区，设置不同的防火墙 2.Scalability - 动态伸缩， 至少支持两个维度的伸缩，比如水平伸缩和垂直伸缩。 可参考的实践： 根据用户访问量或系统负载，进行水平的增加或者减少服务器实例 可根据Segment分流，比如产品线类型，多品牌划分。 3.Resilie ...

背景事故发生在某个工作日下午，初诊症状为页面响应时间巨长，没有任何反应，页面一直处于加载状态中，根据后端监控平台显示，相关服务的所有实例CPU占用率达到100%，为了快速恢复服务，及时止损，果断决定在负载均衡后，依次重启一半的实例，然后再进一步观察是否能处理正常的业务流量，不幸中的万幸，这招管用了，如果不管用，可能就需要通过蓝绿部署进行回滚操作了（但这样会将最新版本的一些功能进行回滚）。但这种管用是临时还是永久的呢？ 根因分析难道万能的重启大法能治百病？当然不是，任何一次产品事故都是难道的学习机会，往往这样的经验还非常的宝贵，于是根因分析必不可少。我们很快在服务暂时恢复正常后，即刻开始了进一步的调查工作？通过分布式追踪平台，很快定位到了调用链上面有问题的服务，针对有问题的服务进行进一步分析，CPU占用率100%往往只是表象，导致它的原因才是我们真正关心的点；如下图，根据可视化的日志，发现频繁的Full GC占用了大量的CPU时间片，并且Stop the world，挂起了应用进程，导致服务可用性的降低： 在GC策略上面，我们的服务默认都是选择的CMS，在可达性分析的时候, 一般会 ...