微服务架构可以说是目前最流行的架构了，我终于也要上这条船了，为什么要上这条船呢，只是为了时尚吗？呵呵，当然不是，上这条船是为了实用的。
先说说现状。现有的系统简单、粗暴。开发是采用c#和dotnet framework 4.5框架，部署采用的是单节点单实例的方式来部署的。在一台windows云服务器的IIS中部署多个站点。只是简单的做了业务分层，把后台API独立为一个站点。对外服务的网站和公司内部使用的管理系统各自独立为一个站点，并和微信小程序、APP都依赖于一个webapi站点提供服务。在这种架构模式下。发生过很多次网站宕机的情况，还出现整个服务器宕机，必须重启的情况。
在公司初创初期，这套系统以最低的成本为公司的发展提供了足够的技术保障，但是随着业务量的逐渐增长，这套架构已经不堪重负了。所以，是时候重构整个系统了。目标就是提高整个系统的可用性、负载能力和可维护性。为公司下一步业务的增长提供一个坚实的依托。
架构选型
其实也没什么好选的。目前最流行的就是微服务架构了。而且这套架构也确实能提高整个系统的可用性和负载能力。
实施选型
框架选定了，怎么实施呢。在实施的时候要遵循什么原则呢。结合我们的业务需要和团队技术背景能选的方案其实并不多。一个微服务架构由那些东西构成呢。第一个就是提供某种业务能力的服务了（废话），有了业务服务就要有一个东西来管理这些服务，提供起码的服务注册和服务发现以及服务健康监控能力。为了提高系统的可用性和负载能力对于热点微服务肯定需要部署多个实例，并在这些实例上进行负载均衡和流量控制。同时还要把这些多实例的情况进行隔离，让调用者看起来犹如一个服务一样。服务多了，就需要为这些服务提供统一的身份认证，让系统的水平扩充简单方便。为了提高系统的维护性就需要有监控和审计的能力。
基于以上需求，要实现微服务架构除了服务本身之外还需要一个服务管理中心来提供服务注册、发现和健康管理能力。需要一个API网关来实现负载均衡、流量控制、身份认证、日志收集系统监控和调用隔离。
在经过多方考察后最终决定使用如下的方式来实施微服务架构。
开发语言和技术框架
开发语言依旧使用C#，技术框架选用dotnet core 2.0。采用这套技术框架的迁移成本是最低的啦。
微服务
微服务采用dotnet web api进行构建，服务间的调用也用webapi的方式调用。
服务管理中心
服务管理中心采用consul来实现。
API网关
API网关基于Ocelot进行定制开发。
部署
微服务全部采用docker的方式部署。
实施步骤
搭建实验部署环境；
开发原型系统；
在实验环境中部署原型系统；
进行故障测试、可用性测试和可维护性测试。
