一、微服务选型
在做微服务架构的技术选型的时候，以“无侵入”和“社区活跃”为主要的考量点，将来升级为原子服务架构、量子服务架构的时候、甚至恢复成单体架构的时候，代价最小。
软件开发只需要组装，不再需要从头开发。
选型可以参考一下张队长的文章：https://mp.weixin.qq.com/s/UIFjm7W6bDfdmjpeMVJtqA
二、微服务架构是什么？
每一个微服务都是一个零件，并使用这些零件组装出不同的形状。微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统。
服务之间互相协调、互相配合，为用户提供最终价值，每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相协作，通常是基于HTTP协议的RESTful API或者RPC。
核心思想：把大系统拆分为小系统。
服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
负载均衡:
服务网关：服务网关是服务调用的唯一入口。
配置中心:
API管理：
集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
分布式事务：保证数据的一致性
调用链 ：记录完成一个业务逻辑时调用到的微服务，并将这种串 行或并行的调用关系展示出来。在系统出错时，可以方便地找到 出错点。 （监控）
支撑平台：由于微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，就需要用到自动化.
微服务与单体的比较，可看下图：
什么时候选用微服务呢？
从个人来看，有三种场景可以考虑使用微服务
1、规模大 ，团队超过10人
2、业务复杂度高，系统超过5个子模块
3、需要长期演进，项目开发和维护周期超过半年
五、快速体验微服务架构
使用微服务简单模式进行开发的四个步骤：
1、沿用组织中现有的技术体系开发单一职责的微服务
2、服务提供方将地址信息注册到注册中心，调用方将服务地址从注册中心拉下来。
3、通过门户后端（服务网关）将服务API暴露给门户和移动APP。
4、将管理端模块集成到统一的操作界面上。
六、运维
基础设施：自动构建、自动部署、日志中心、健康 检查、性能监控等功能
gitlab-CI/CD、Jenkins+gitlab-CI/CD：自动化部署
K8s&Docker+Jenkins&Pipeline+Gitlab--CI/CD：自动化部署
ELK:日志
zipkin/skywalking：微服务监控
我们只需要在开发 层面理解了注册中心、服务发现、负载均衡、服务网关和管理端集成框架， 在运维层面准备好持续集成工具、配置中心和监控告警工具，就可以很容 易地落地微服务架构，享受微服务架构带来的精彩。祝大家玩得愉快。
八、微服务架构API的开发与治理
1、开放给互联网用户调用的API需要在API网关上加上授权、鉴权、限流、限并发、统计、计费等功能
2、内网环境：提供给内网里的其他微服务调用的API。
1、内网环境API开发1、需要先考虑是用HTTP API还是RPC？
HTTP API：
指的是简单的基于HTTP协议的API，具体的例子就是MVC的Controller,
RPC:
远程过程调用(大多数指Socker通信方法的远程调用)，也可以使用HTTP协议来实现RPC调用，例如gRPC.
HTTP 简单、RPC基于Socket的RPC性能更好。但我最后还是选择了HTTP API来使用。
2、HTTP API 的性能足以支撑多数项目RPC的协议吞吐量是HTTP性能的几倍，如 protobuf、Thrift、Kyro、Dubbo
等，在考虑自身技术栈、成本、稳定性、易用性、可维护性、业务场景等因素考虑，HTT和RPC的性能差别并不是主要问题。