微服务不是单独存在的。为了更好的实现微服务架构，需要将众多的组件进行集成和混搭，才能打通任督二脉，立于不败之地。网上很多高手都讲微服务治理，也有人片面讲微服务，比如springboot、docker。本文着重于组件选择的对比，也积累了我们团队多次PK的精华；这些组件包括springboot、springcloud、docker、服务注册发现、RESTFUL、postman、jenkins、ELK、etcd等。背景随着公司一年多的成长，我们开发了几十个项目，包括JAVA和PHP在后台。为了更好的提高开发和管理的效率，技术大牛和特立独行者经常会进行激烈的PK，碰撞出许多爱情的火花，比如其中之一：微服务实践。设计一个微服务开发架构只需要一套BASE微服务。BASE微服务生成业务系统微服务实例，供各业务系统调用；业务系统不直接调用BASE，只能调用微服务INSTANCE。问题一：有人会问，如果有20个业务系统，那么微服务就有几百个，这怎么管理？这是运维的问题。让运维解决吧。使用工具进行运维并不难。反正脚本都执行了，不需要手动操作。问题2：为什么不做一个saas微服务，这样微服务不到10个，就很容易管理了是不是？单点故障影响大局，所以我们选择稳定性更重要；另外，在saas的情况下，为了应对不同的行业，会有过度设计的嫌疑；私有化更容易。调用逻辑Callinglogic客户端调用业务系统，不直接调用微服务；微服务内部也存在调用关系。设计理念1.模块化是非模块化的基础，更何况是微服务。比如用户微服务、产品微服务、地址微服务首先都需要模块化。为了更好的实现开发，你可能不得不同时进行模块化和微服务化。模块化的时候注意不要有关联查询，而且封装必须是完全独立的，这样才能拆解微服务。微服务在模块化这边松耦合强内聚，意味着我们的模块之间不直接依赖，无状态，可以独立对外提供服务；强内聚意味着我们虽然要拆分成小的微服务，但是也要考虑某些功能的强关联性。例如，一张凳子是由四条腿和一块板组成的。如果不能把四腿和板子分开卖，就没有意义。开发强大友好的spring系统5年多的java开发很清楚，很多JAVA框架已经淡出了人们的视线，比如hibernate，struts1，struts2，只有spring越来越流行。spring-boot：比springmvc简单。springmvc有大量的配置文件，如spring-servlet、spring-mybatis、spring.xml、web.xml等。spring-boot不需要这些，只需要强大的注解功能就够了，boot更适合微服务。spring-cloud：里面有很多组件，用于支持微服务，比如springcloudconfig统一配置中心，用于多环境配置文件配置。我担心配置文件管理；springcloudeureka用于服务注册和发现，下面单独介绍；其他组件大家可以去官网看看，这里就不一一介绍了。总之，如果使用JAVA平台，尽量使用spring系统的内容。我们使用mysql作为数据库，因为我们的应用比较多，但是单表的数据量不会太大，单表的数据量不超过百万。我们还尝试了mongodb。开发速度非常快，也非常灵活，但由于不是关系型数据库，维护成本较高。授权认证是为了外部验证和内部完整的信任机制。授权认证接口规范RESTFUL：URL资源和操作解耦，使得URL更加语义化，成百上千的接口也非常容易管理。网上有很多文章解释的很透彻。这个东西不是特别好理解。你需要了解更多。在项目实践中，有一种矛盾的感觉，这里就不详细介绍了。接口文档swagger：相对于传统手工编写接口文档，swagger有统一的输出格式，不管多少人写；swagger使用代码编写来编写接口文档。如果之前修改过代码，必须打开wiki手动修改接口Documentation，现在只需要修改代码，程序员更愿意修改，成本更低，前端和其他调用者不会大喊大叫每天，你的界面又变了，新的字段是什么意思？.服务注册与发现：eureka服务接口改变后，不需要口头通知服务调用者，因为调用者太多，你不知道他是谁，错过是难免的；可以支持PHP。服务注册发现消息队列RocketMQ：一直纠结kafka和rocketMQ，最终选择了RocketMQ异步编程方式。出于性能考虑，尽量使用异步编程，比如注册发优惠券。如果注册成功，用户可以返回注册成功，但是Sendingcoupons可以异步调用，不会阻塞注册线程。实时日志分析平台ELK微服务框架下，日志不可能分散在各个服务节点上，必须有一个统一的日志中心。ELK是一个实时日志分析平台，将各个服务的日志收集在日志中心，然后可以根据系统，节点等进行搜索，除了上面的搜索条件，我们还实现了业务id(由一个请求生成)在每个微服务中一个业务id)和用户id来搜索日志，方便跟踪定位问题。当然统一配置中心ETCD可能有更轻量好用的disconf或者springcloudconfig，但是我们有php开发的应用，两者都不支持。如果都是JAVA应用，用disconf还是很不错的。测试微服务接口测试工具postman每个程序员都有这样的经历。刚上线，客户就反馈了bug。原来，当我们修改某个功能代码时，导致了其他功能的bug。每次上线都不介意，这体现了接口测试的必要性，尤其是每次版本升级，都需要执行一次，防止一个接口的修改导致其他接口出错，这就多了比手动测试更可靠。部署微服务的好朋友：docker已经家喻户晓。这是继虚拟机之后的又一次重大变革。所有的个体微服务都放在docker里面，这样你想什么时间什么地方部署，扔过去就行了。好吧，它要爆炸了。负载均衡工具：dockerswarm简单的几条命令就可以搞定负载均衡，也可以平滑升级。银行正在进行系统升级和维护，请不要取钱，因为你可能取不出来，呵呵。升级数据库。在升级之前对数据库进行物理或逻辑备份。数据库脚本不能包含删除或修改表和数据的语句，以防止旧业务在升级过程中报错。运维人员上线前必须检查所有脚本。我们使用一些敏感词drop或delete工具flyway可以对数据库脚本进行版本控制。传统版本升级持续集成，1.开发推送代码，记录你提交了哪些文件；2、项目经理根据svn审核文件，打包成war包；3、放入测试公司的测试环境进行测试；4、中途修改了文件，可能需要重新打包；……写不下去了，项目经理超人一样。现在使用持续集成（CI）非常简单。我们使用的工具是Jenkins。推送代码后，只需单击几下按钮即可完成启动。不管是测试环境还是生产环境，都很简单。不然项目经理查完资料就眼睛都绿了。向上。End最后说明一下，本文主要介绍微服务开发的选型，具体细节不赘述。如果您有兴趣，可以了解每个组件。当然，我们的选择是正确的，不同场景下的应用可能完全不同。本文仅供参考。
