微服务架构选型该如何实践
这期内容当中小编将会给大家带来有关微服务架构选型该如何实践，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。
为寒亭等地区用户提供了全套网页设计制作服务，及寒亭网站建设行业解决方案。主营业务为成都做网站、成都网站建设、寒亭网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
设计
微服务开发架构.png
只需要有一套 BASE 微服务，BASE 微服务生成业务系统微服务实例，供各个业务系统调用；业务系统不直接调用 BASE，只能调用微服务 INSTANCE。
问题一：有些人会问，假如有 20 个业务系统，那就有上百个微服务，这怎么管理得了？
—- 这是运维的问题，让运维去解决，运维使用工具，实际也不算困难，反正执行的都是脚本，不需要手工操作。
问题二：为什么不做成一个 saas 的微服务，这样就只有不到 10 个的微服务，就非常容易管理了不是吗？
—- 单点故障影响全局，我们选择了稳定更重要；另外 saas 的话，为了应对不同行业，会存在过度设计的嫌疑；私有化更容易。
调用逻辑.png
客户端调用业务系统，不直接调用微服务；
微服务内部也存在调用关系。
模块化是基础
非模块化，谈不上微服务，比如我们上面的用户微服务、产品微服务、地址微服务等，都需要先模块化，为了更好地落实开发，你可能不得不，边模块化边微服务，模块化的时候要注意，不能有关联查询，包要完全独立，到时候微服务才能拆开。
边模块化边微服务.png
松耦合、强内聚
松耦合表示我们模块之间不直接依赖，无状态，可以单独地为外界提供服务；
强内聚是指，我们虽然要拆分成一个个小的微服务，但是也要考虑某些功能的强关联性，比如一个凳子是由四个脚与一个板组成，我们不能把四个脚与板分开售卖，就没有意义了。
开发
java 开发 5 年以上的都非常清楚，很多 JAVA 框架都淡出了视野，比如 hibernate、struts1、struts2，唯有 spring 越来越受欢迎。
spring-boot: 较 springmvc 更加简约了，springmvc 有一大零的配置文件，比如 spring-servlet、spring-mybatis、spring.xml 与 web.xml，这些在 spring-boot 都不需要了，只需要强大的注解功能即可，boot 更合适微服务。
spring-cloud: 里面有比较多组件，用于支持微服务，比如 spring cloud config 统一配置中心，用于多环境的配置文件配置，大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了；spring cloud eureka 用于服务注册与发现，下面有单独介绍；其它的组件大家可以去官网看看，这里不一一介绍，总之如果 JAVA 平台，尽量使用 spring 体系的内容。
我们采用 MySQL，因为我们是应用多，但数据量单表并不算大，多则不超过百万，MongoDB 也实验过，开发非常快，也非常灵活，但因为不是关系型数据库，维护成本较高。
针对外部校验，内部完全信任机制。
权限认证.png
RESTFUL：URL 的资源与操作解耦，让 URL 更加符合语义，上百个接口也非常好管理，网上有很多文章讲得非常透彻，这玩意不是特别好理解，要多领悟，在项目中实践，就有矛塞盾开的感觉，这里不做详细介绍。
接口文档 swagger：比起传统全手工写接口文档，swagger 有统一的输出格式，不管是几个人写的；swagger 采用写代码的方式来写接口文档，以前修改了代码，还必须打开 wiki 手工修改接口文档，现在只需要修改一下代码即可，程序员更愿意修改了，成本更低了，前端与其它调用者不会天天吼着，你这接口咋又变了，新加的字段是啥意思呀。
服务接口改变后，再也不需要口头通知服务调用者了，因为调用者太多，你根本不知道他是谁，难免遗漏；可支持 PHP。
服务注册发现.png
RocketMQ：一直纠结 kafka 与 rocketMQ，最终选择了 RocketMQ，这里有详情介绍http://www.jianshu.com/p/453c6e7ff81c
为了性能上面的考虑，尽量使用异步编程，比如注册送优惠券，那么注册成功就可以给用户返回注册成功了，但是送优惠券可以是异步调用的，不阻塞注册的线程。
微服务框架下，日志不可能还分散在各个服务节点上，必须有统一的日志中心。ELK 是一个实时日志分析平台，就是将各个服务的日志汇总于日志中心，然后可以按照系统、节点等进行搜索，除上述搜索条件外，我们还在各个微服务实现了按照业务 id（一次请求生成一个业务 id）与用户 id 搜索日志，方便跟踪与定位问题。
当然可能有更加轻量级与好用的 disconf 或 spring cloud config，但是我们有 php 开发的应用，以上二者都不支持。如果全是 JAVA 应用，采用 disconf 还是非常不错的。
测试
每个程序员都有这样的经历，刚上线，客户又反馈了 bug，原来是我们修改某个功能代码的时候，导致了其它功能的 bug，每次上线心里都没底；这就体现了接口测试的必须性，尤其是每次版本升级的时候，都需要执行一遍，以防修改某个接口导致其它接口报错，比手动测试靠谱许多。
部署
docker 已经家喻户晓了，这是继虚拟机以后，又一重大变革，将所有的单个微服务都放在 docker 中，这样你何时何地想部署，直接丢过去就 OK 了，快到爆。
用几句简单的命令就搞定了负载均衡，而且还可以平滑升级，版本升级的时候，大家就不用告诉客户：系统通知，某日某晚 00:00-08:00 我行处于系统升级维护中，大家不要去取钱哦，因为你可能取不出来，呵呵。
升级
升级前对数据库做物理或逻辑备份
数据库脚本不能含有删除或修改表与数据的语句，防止升级过程中旧业务报错
所有脚本上线前运维人员必须 check，一些敏感词 drop 或 delete
我们采用工具 flyway，可以对数据库脚本进行版本控制。
传统的版本升级，1. 开发推代码并同时记录自己提交了哪些文件；2. 项目经理根据 svn 审核文件，并打包成 war 包；3. 投到测试环境让测试公司测试；4. 中途修改了文件，可能需要重新打包；我都写不下去了，项目经理像个超人似的。
现在用持续集成（CI）非常简单，我们用的工具是 Jenkins，推完代码，点几下按钮就完成了上线，不管是测试环境，还是生产环境都非常简单，不然项目经理核对文件眼睛都绿了。
上述就是小编为大家分享的微服务架构选型该如何实践了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。
当前题目：微服务架构选型该如何实践
本文来源：http://ybzwz.com/article/jiisgi.html
