微服务系统设计(元素)
以springboot框架来设计一个微服务系统,可以利用现有的springcloud微服务体系，可以大大节省开发人员的开发时间
springcloud解决的是企业开发过程中，会遇到的各种问题，节省企业效率。但这些框架对开发者的技术提升或对技术的理解来说并不是好事。这就相当于公司买了一些技术产品，然后开发的过程中，技术人员调用它们，要在以前这些技术产品都要技术人员开发,现在开发人员完全纯写业务。对技术有追求的人，对springcloud做到会用就行。
任务一门技术或框架的诞生都是围绕着企业开发遇到的问题而应用而生的，这可以技术人员看轻技术的一个原因。
以企业遇到的问题为例:
配置文件(配置中心)-springcloud-config
服务治理(zookeep)-springcloud-eureka
网关-springcloud-zuul
客户端负载均衡(服务器端负载均衡)-springcloud-ribbon(feign)
一直希望可以做些有挑战的项目，很多事情也是可遇不可求。
话外(如何保证消息队列的消息按顺序消费):
这里面涉及到2方面问题：
生产者按顺序；
消费者按顺序；
对于生产者按顺序：
在发送的消息上加标识，经过hashcode得到相同值，发送到固定的队列。对于kafka而言，即为partion。这样可以保证消息按顺序发送
这里会有一个问题，即发送A、B2个消息，发送A成功了，而发送B失败了。这种情况kafka是怎么解决的呢。
https://blog.csdn.net/thekenofDIS/article/details/79973589
即为：
在发送阻塞前对于每个连接，正在发送但是发送状态未知的最大消息数量。如果设置大于1，那么就有可能存在有发送失败的情况下，因为重试发送导致的消息乱序问题。
所以我们应该将其设置为1，保证在后一条消息发送前，前一条的消息状态已经是可知的。
还可以借鉴TCP发送消息的机制，多个发送的消息根据某些协议是一个整体，在消费端对消息进行校验，当接受到消息A时，根据协议计算出是否有后续消息
或者合并多个消息为一个消息，但这是消息设计耦合度或许有点低
对于消费段而言：
如何队列里面的消息是顺序是有序，那当然“消费”时候也是有序，这里的消费指的是接收消息的顺序，不能代表消息处理完成的顺序
整体而言：
按顺序消费的实质是处理的消息应该有先后顺序，有先后顺序的消息之间应该有某种关联性，例如有2个消息，（它们有相同的key值），A和B，随意发送到消费端，先持久化到数据库中，统计当此key的消息统计有2条值，说明2个消息都获取到了，然后再按顺序消费2个消息。