当前各种云平台、开放平台满天飞，大到互联网巨头小到垂直行业头部有野心的企业，都会有搭建云平台的冲动。技术上也有各种高大上满天飞的，但是最终落地还是需要结合自身实际情况和业务需求，考虑性价比来执行。往往是从丰满到骨感，引无数大牛尽折腰。好了，不多说了，找个合适的给大家看看
1、为什么要构建微服务
所有架构方案的提出都是根据应用场景进行优化的，想一下5年前，当时springmvc大行其道，使用ssm 构建应用基本上是当时开发界的标准。当时的数据量还没有进行服务拆分，所有服务构建在一个单体应 用中，所有服务间调用是通过http请求实现的。
但是这种方式构建的应用有几个最主要的缺点：
1、当请求量和并发量上来后，服务扩展比较困难，单体应用可以实现集群化提供服务，但需要配置前 端代理服务器，如果并发量降下来后又要回收服务资源修改配置。
2、所有服务共用一个后端数据库资源，这样数据库就成为了性能瓶颈。
3、单体应用一旦挂掉，整个服务将不能提供应用，比如一个服务中提供了下单、浏览、注册服务，如 果所有接口构建在一个服务中，那么当出现问题时所有功能都不可用。
以上只是列举了几个单体应用可能遇见的问题，微服务提出就可以解决以上出现的问题，将大的服务拆 分成多个小应用提供服务，每个服务单独使用各自的数据库资源，这样就实现了“不把鸡蛋放在一个篮 子里”，当某个服务宕机后，最多那个服务不可用，其他资源还可继续使用。
2、微服务的优势与劣势
微服务拆分最大程度上解耦了应用，但是也一样带来了服务的复杂度，比如要查询用户的订单信息，在 早期的架构方案中，这两个数据是存储在一起的，通过一个表关联查询出数据；但是在微服务下这样就 实现不了了，因为这两个数据是存储在不同位置，如果要查询这两个数据，需要到两个服务中分别取出 来然后再组装起来返回给客户。
微服务优点：
1、服务解耦：不同的服务拆分成不同的应用对外提供服务
2、方便扩展：如果某个应用并发量很大，对单个应用进行扩容，当请求量将下来后再回收资源
3、数据解耦：将不同的应用数据存储在不同的数据库中，这样就实现了数据的水平拆分
微服务的缺点：
1、增加了服务的复杂性，原来一个请求就能获取到的数据，微服务化后可能需要多次请求才能获取到 结果
2、维护成本增加了，不同的应用需要不同的人员进行维护
3、架构复杂，增加了问题排查和定位的难度
3、docker容器化实现动态伸缩
如果只是对服务进行拆分，并没有体现出微服务的优势，对于动态扩容和伸缩还是需要人员来参与，所 以云平台在构建的时候考虑到了这些，在服务拆分同时，使用的k8s进行服务治理，实现动态扩容和伸 缩，同时使用elk进行日志收集和分析，这种架构基本实现了我们的业务需求：
1、服务和数据拆分，不同服务的数据存储在不同的数据库，对数据库进行水平扩展
2、日志统一收集处理，排查和定位问题方便
3、使用k8s进行服务编排和治理，可以实现资源动态伸缩，方便管理
4、云平台整体架构
云平台整体使用的springcloud构建微服务，微服务构建使用docker部署在k8s中，对外通过统一的
nginx做请求转发，应用服务和数据存储之间使用redis缓存。
