相信大家现在都在用微服务，不管用的好坏，对于微服务这项非常有前景的技术，都是需要做一些了解，本文摘抄了之前看到的文章，并加上个人的理解，供分享。
目录
4个基础
8个关键
最后的一句话
4个基础
TOGAF：全称“开放组体系结构框架”，如今，大家手机里正在使用的产品和应用中，很多都会用到SAP、IBM或者惠普的软件，而这些软件公司所遵循的就是TOGAF。TOGAF是一个架构体系，并没有提供具体的架构方法。TOGAF有三个最为主要的支柱：
- 企业架构域，主要是企业信息与业务流等；
- ADM一系列的架构方法论；
- 企业连续性，指的是在企业业务高速增长并且不断变更的过程中，保证架构体系的连续性。
是不是似曾相识？其实做过项目的都知道上述原则，我也是刚刚才知道TOGAF，看来理论知识还是老美搞的好。
DDD：全称为“领域驱动设计”，三句话进行概括：
- DDD是精简的业务，DDD首先关注的就是业务，把各种繁琐的业务流程精简成更细的链条；
- DDD需要回答业务是干什么的，能够满足什么需求，达成什么目的；
- 不断迭代，DDD的不断迭代与TOGAF的企业连续性类似。
这个可以作为TOGAF的升级版，放在这里可以看出架构的进化。
SOA：全称为“面向服务架构”，总结为以下三点：
- SOA解决了信息孤岛的问题；
- 业务重用，从业务角度将各个服务组合成一个个中间件或者服务，将其提供给用户或者其他系统；
- SOA使得系统成为互联互通的信息群。
看到又升级了，SOA的确是这10年来一直比较火的架构。
GRASP原则：全称为“通用职责分配原则”，与设计模式不同，设计模式指导如何实现系统，而GRASP旨在指导如何划分。三个关键：
- 自己干自己的事；
- 自己只干自己能干的事；
- 自己只干自己的事，强调了资源划分。
这个基础是最容易理解的，面向对象和设计模式里，一直在贯彻这个原则，其实在实际的工作中，我们在人员的职责划分上，也是遵循这个原则的，任何时候，都不能越俎代庖，否则工作上会困难重重，其实在微观的开发架构上，也是如此。
8个关键
1. 小即是多
这个是显而易见的，微服务架构要比之前单个模块的开发工作大多了，如何拆分就是一个大问题，只有对业务领域足够的了解，才能把服务拆成合理的颗粒度。
2. 债务管理（代码缺陷）
感觉还是用代码缺陷比较合适，俗话说，做的越多，错的越多。微服务由于拆分以后，会变成很多个单独执行的服务，增加了出错的概率，这就需要一些方法来减少债务。比如：单元测试、集成回归、版本管理、迭代冲刺、回归总结
3. 服务依赖
这个还是与第一点有点儿联系，也容易理解，解决的方法也有，比如：服务发现、依赖唤醒、灰度发布、AB测试、多版本共存
4. 消息通讯
既然都已经微服务了，那么肯定少不了服务之间的通讯，这就需要一个统一的通讯机制。其实这一点在战争中经常可以体现出来，比如二战期间德国的恩格玛密码，各军种统一使用，保证了信息的一致和通畅。
5. 分布式事务
这个倒是没有想到，微服务中也会用到事务，由于微服务部署肯定都不在一台服务器中，所以事务一定是跨机器或者跨网络的，分布式服务的确也是需要的，这里有两个原则：2PC或者3PC，2PC原则是通过全部节点投票和执行两个步骤完成的，并且是阻塞的；而3PC则不同，虽然在一个具体的事务里面可以是阻塞的，也可以是非阻塞的。
6. 花式故障
可以想象，一旦发生问题，要从几十甚至几千个微服务中找到问题原因，将多麻烦的一件事情，好在目前有一些方法可以应对：比如全链路追踪，比如使用Open Tracking；主动拨测，很多用户端的APP里面内置探针，使其可以接收Server端的指令来定期探测接口和服务是否正常。
7. 中心与去中心
去中心很火，但是对于开发和运维而言，中心化是必不可少的，否则真的是“上线一时爽，运维火葬场”，比如配置中心、日志中心、调度中心、状态中心、预警中心等等。
8. 组织危机
这一点与开发人员关系不大，更多的是涉及到团队管理人员，微服务开发，对于人员的调度分配、语言的协调等都是不小的挑战。
最后的一句话
不要让重复的事情做三次。原话是两次，我还是改为三次，中国传统古语讲，事不过三，是有道理的，天道无亲。
