微服务架构的出现

在软件开发早期，大部分服务都是单体应用，像很多第三方集成也都是sdk接入，而且硬件资源很贵，所以一个软件其中包含的代码非常多，不便维护，并且在发布的时候，编译就需要很长时间，而且很多小的改动就要发布一整个的软件，并且当软件规模越来越大的时候，很多团队维护这个单体应用，不论从测试，还是发布都是非常不方便的。
这时候就出现了微服务，但是还没有到架构层级。首先，出现了很多概念，比如说rpc，restful，等等。很多服务之间已经可以根据这种协议来进行数据交互，在软件解耦合方面已经有了一定的进展，尤其后期dubbo，thrift，spring cloud，grpc这些框架的出现都在一定程度上解决了单体应用的问题。这些框架不仅解决了解耦合的问题，也提供了统一管理的这种概念，比如利用注册中心做服务发现，解决了点对点ip地址维护复杂等问题。

微服务架构解决的问题

很多人对微服务架构的理解是解决单体访问速度慢的问题的，这样其实是大错特错的，访问速度慢有很多问题，比如高并发，数据量大查询慢等等，这些并不是说用了微服务架构就能解决的问题。
微服务架构的出现，一是解决了团队工作配合的问题，各个团队之间不再具有高度耦合性，每个服务都是独立的模块，不会出现一个问题影响全局这种情况。其次，微服务带来的应该是稳定，而不是更快，某个服务挂了不会影响全局，部署方式也更加灵活，服务之间低耦合，服务之内高内聚，针对微服务做内存，cpu等优化会更具有针对性。

微服务架构会带来的问题

当然了，凡事都有两面性，将单体拆分为微服务一定会带来一些问题，毕竟单体之间都在一个进程内，改为微服务以后就会出现网络问题，如果曾经对进程内部做过很多优化，做成微服务以后，就会将这些问题与网络关联起来，像分布式锁，分布式事务，负载均衡，由于服务器变多了，运维的压力也就上来了，除了这些，线上环境千变万化，还有很多问题都是我们不能预估的。

微服务架构的设计

由于现在互联网的兴起，很多线上产品压力都是很大的，不论从流量，稳定性各个方面都会有，微服务架构设计不可避免，我觉得从设计上，减少分布式事务和锁的出现是设计的第一要素，要让服务之间耦合变低，如果有这些需求，那这就不能作为一个高并发的系统，要做限流等工作，服务稳定是第一位的，还可以借鉴数据库分库分表的思想去以领域的方式划分服务，减少接口的无用访问等等。