微服务

使用Akka-Http构建REST风格的微服务，服务API应尽量遵循REST语义，数据使用JSON格式交互。在有错误发生时应返回： {"errcode":409,"errmsg":"aa is invalid，the ID is expected to be bb"} 类似的JSON错误消息。 代码： https://github.com/yangbajing/akka-action http://git.oschina.net/yangbajing/akka-action 代码 首先来看看代码文件结构： ├── ApiRoute.scala ├── App.scala ├── ContextProps.scala ├── book │ ├── Book.scala │ ├── BookContextProps.scala │ ├── BookRoute.scala │ └── BookService.scala └── news ├── News.scala ├── NewsContextProps.scala ├── NewsRoute.scala └── NewsService.scala 通过名字可以看出， App.scala 是启动程序，以 Route 结尾的是API路由定义文件， Service 结尾的就是服务实现代码了。 ContextProps

这个神器就是 CommandLineRunner，ApplicationRunner CommandLineRunner 接口的 Component 会在所有 SpringBeans都初始化之后， SpringApplication.run()之前执行，非常适合在应用程序启动之初进行一些数据初始化的工作。 如果我们在启动容器的时候需要初始化很多资源，并且初始化资源相互之间有序，那如何保证不同的 CommandLineRunner 的执行顺序呢？Spring Boot 也给出了解决方案。那就是使用 @Order 注解。 用法： @Component @Order(1) public class OrderRunner1 implements CommandLineRunner { @Override public void run(String... args) throws Exception { System.out.println("The OrderRunner1 start to initialize ..."); } } 注意：一定要有@Component这个注解。要不然SpringBoot扫描不到这个类,是不会执行。 添加 @Order 注解的实现类最先执行，并且 @Order()里面的值越小启动越早。 在实践中，使用 ApplicationRunner 用法相同 来源

本文节选自《疯狂Spring Cloud微服务架构实战》 京东购买地址： https://item.jd.com/12256011.html 当当网购买地址： http://product.dangdang.com/25201393.html Spring Cloud教学视频： https://my.oschina.net/JavaLaw/blog/1552993 Hystrix属性配置与回退 属性配置 使用Hystrix时，可以为命令设置属性，以下的代码片断，为一个命令设置了执行的超时时间： public MyCommand(boolean isTimeout) { super( Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup")) .andCommandPropertiesDefaults(HystrixCommandProperties.Setter() .withExecutionTimeoutInMilliseconds(500)) ); } 以上的配置仅对该命令生效，设置了命令的超时时间为500毫秒，该配置项的默认值为1秒，如果想对全局生效，可以使用以下的代码片断： ConfigurationManager .getConfigInstance() .setProperty(

本文节选自《疯狂Spring Cloud微服务架构实战》 京东购买地址： https://item.jd.com/12256011.html 当当网购买地址： http://product.dangdang.com/25201393.html Spring Cloud教学视频： https://my.oschina.net/JavaLaw/blog/1552993 Spring Cloud电子书： https://my.oschina.net/JavaLaw/blog/1570383 Hystrix运作流程 在前面的例子中，使用Hystrix时仅仅创建命令并予以执行，看似简单，实际上，Hystrix有一套较为复杂的执行逻辑，为了能让大家大致了解该执行过程，笔者将整个流程作了简化。Hystrix的运作流程请见图6-3。 图6-3 Hystrix的运作流程图 简单说明一下运作流程： 第一步：在命令开始执行时，会做一些准备工作，例如为命令创建相应的线程池（后面章节讲述）等。 第二步：判断是否打开了缓存，打开了缓存就直接查找缓存并返回结果。 第三步：判断断路器是否打开，如果打开了，就表示链路不可用，直接执行回退方法。结合本章开头的例子，可理解为“基础服务”模块不可用，“服务A”模块直接执行回退，响应用户请求。 第四步：判断线程池、信号量（计数器）等条件，例如像线程池超负荷，则执行回退方法

【编者按】本文作者为 Matt McLarty，通过介绍 SOA 的兴衰变化，总结了微服务应该借鉴的5条经验教训。文章系国内 ITOM 管理平台 OneAPM 编译呈现。 ##SOA 的兴衰变化让我们更了解如何充分利用微服务 正如笔者在上文《 微服务架构是敏捷软件架构 》中提到的，笔者对微服务架构的第一反应，就是质疑它跟面向服务架构（SOA）有何区别。还有很多人将这两种架构联系在一起。詹姆斯·刘易斯和马丁·福勒在他们的 权威博客 中包含了一个侧边栏，进行 微服务和 SOA 的对比 。对此，怀疑派做出的回应是二者之间 并无不同 。实际上，在“微服务”这个名词出现之前，使用微服务的 亚马逊 和 Netflix 都谈到它们使用的是面向服务的架构。两年多之后，关于微服务架构是不是 SOA 的争辩带来了 大量的文章 。 为什么人们这么热衷于对比微服务和 SOA，而且还投入 这么大的激情 ？虽然微服务和 SOA 在很多层面上可以相互区分——架构风格、实施案例、相关技术——但是它们在技术发展全景中起到了同样惊人的作用。它们都有望转变整个格局，而且都成功吸引了一大批拥护者。简单来说，微服务和 SOA 都以架构开始，但是最终都成了一场运动。 可惜啊，现在 SOA 在 IT 业内基本上被视为一场失败的运动，而很多为它投入时间、金钱和精力的人的伤痛依然清晰可见

1 Zuul介绍 通过前几个核心组件，可以构建一个简略（不完善）的微服务架构： 在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。 当前架构存在的不足： 首先，破坏了服务无状态特点。为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外可续对接口访问的控制处理。 其次，无法直接复用既有接口。当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。 解决思路： 需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器，也就是服务网关。 服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud

一、逃离单体系统，拥抱微服务？ 单体系统和微服务的区别在于，一个单体系统是一个大而全的功能集合，每个服务器运行的是这个应用的完整服务。而微服务是独立自治的功能模块，它是生态系统中的一部分，和其他微服务是共生关系。现在，业界对单体系统和微服务的普遍观点是：单体系统非常容易开发、测试、部署，但是单体系统面对的问题也很多，例如开发效率变低、维护成本增加、部署影响变大、可扩展性较差、技术选型成本高，而引入了微服务可以实现每个微服务易于开发与维护，便于沟通与协作，很适合小团队敏捷开发与持续交付；每个微服务职责单一，高内聚、低耦合。同时，每个微服务能够独立开发、独立运行、独立部署；每个微服务之间是独立的，如果某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响；每个微服务可以随着系统规模的不断扩大，面对海量用户和高并发，独立做水平扩展与垂直扩展；每个微服务可以使用不同的编程语言以及不同的存储技术，使得我们更容易尝试新的技术。此外，对单个服务进行业务重构，也不会面临很大的业务负担与技术债券。 笔者对微服务系统的观点是，我们从单体系统向微服务系统改造的过程中，需要认真思考什么阶段使用微服务。微服务不是银弹，它对于设计和运维难度提出了更高的要求，同时也带来了一些技术的复杂度。因此，我们需要思考与解决分布式的复杂性、数据的一致性、服务的管理与运维、服务的自动化部署等解决方案。事实上