微服务架构的演变
4.1如何变化
当我们将所有的新业务都使用Spring Cloud这套架构之后，就会出现这样一个现象：公司的系统被分成了两部分，一部分是传统架构的项目；另一部分是微服务架构的项目，如何让这两套配合起来使用就成为了关键。
这时候Spring Cloud里面的一个关键组件解决了我们的问题，就是 Zuul。在 Spring Cloud 架构体系内的所有微服务都通过 Zuul 来对外提供统一的访问入口，所有需要和微服务架构内部服务进行通讯的请求都走统一网关。如下图：
从上图可以看出我们对服务进行了四种分类，不同服务迁移的优先级不同：
（1）基础服务，是一些基础组件，与具体的业务无关。比如：短信服务、邮件服务。这里的服务最容易摘出来做微服务，也是我们第一优先级分离出来的服务。
（2）业务服务，是一些垂直的业务系统，只处理单一的业务类型，比如：风控系统、积分系统、合同系统。
这类服务职责比较单一，根据业务情况来选择是否迁移，比如：如果突然有需求对积分系统进行大优化，我们就趁机将积分系统进行改造，是我们的第二优先级分离出来的服务。
（3）前置服务，前置服务一般为服务的接入或者输出服务，比如网站的前端服务、app 的服务接口这类，这是我们第三优先级分离出来的服务。
（4）组合服务，组合服务就是涉及到了具体的业务，比如买标过程，需要调用很多垂直的业务服务，这类的服务我们一般放到最后再进行微服务化架构来改造，因为这类服务最为复杂，除非涉及到大的业务逻辑变更，我们是不会轻易进行迁移。
在这四类服务之外，新上线的业务全部使用Sprng Boot / Cloud这套技术栈。
4.2架构演化的步骤
架构演化的步骤如下：
（1）在确定使用Spring Boot / Cloud 这套技术栈进行微服务改造之前，请先梳理平台的服务，对不同的服务进行分类，以确认演化的节奏。
（2）先让团队熟悉 Spring Boot 技术，并且优先在基础服务上进行技术改造，推动改动后的项目投产上线。
（3）当团队熟悉 Spring Boot 之后，再推进使用 Spring Cloud 对原有的项目进行改造。
（4）在进行微服务改造过程中，优先应用于新业务系统，前期可以只是少量的项目进行了）微服务化改造，随着大家对技术的熟悉度增加，可以加快加大微服务改造的范围。
（5）传统项目和微服务项目共存是一个很常见的情况，除非公司业务有大的变化，不建议直接迁移核心项目。
4.3服务拆分
服务拆分的两个原则：
（1）横向拆分。按照不同的业务域进行拆分，例如订单、营销、风控、积分资源等，形成独立的业务领域微服务集群。
（2）纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。
要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
服务拆分是越小越好吗？微服务的大与小是相对的。比如在初期，我们把交易拆分为一个微服务，但是随着业务量的增大，可能一个交易系统已经慢慢变得很大，并且并发流量也不小。
为了支撑更多的交易量，我会把交易系统，拆分为订单服务、投标服务、转让服务等。因此微服务的拆分力度需与具体业务相结合，总的原则是服务内部高内聚，服务之间低耦合。
4.4微服务 vs 传统开发
使用微服务有一段时间了，这种开发模式和传统的开发模式对比，有很大的不同，如下面几点：
（1）分工不同，以前我们可能是一个一个模块，现在可能是一人一个系统。
（2）架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大。
（3）部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上。
（4）容灾不同，好的微服务可以隔离故障避免服务整体 down 掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。
4.5给数据库带来的挑战
每个微服务都有自己独立的数据库，那么后台管理的联合查询怎么处理？这是大家普遍遇到的一个问题。
有如下三种处理方案：
（1）严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。
（2）将业务相关的表放到一个库中，将业务无关的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库各种切换导致后台统计难以实现，是一个折中的方案。
（3）数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到 NoSQL 数据库中，在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用 Mongodb、Hbase 等。
三种方案在不同的公司我都使用过，第一种方案适合业务较为简单的小公司；第二种方案，适合想在原有系统之上，慢慢演化为微服务架构的公司；第三种适合大型高并发的互联网公司。
4.6微服务的经验和建议
（1）建议尽量不要使用 Jsp，页面开发推荐使用 Thymeleaf
（2）服务编排是个好东西，主要的作用是减少项目中的相互依赖
（3）不要为了追求技术而追求技术
网友评论